Hello Colomban!

This particular one is supported for quite some time, see `comment_use_indent` in Filetypes' settings section <http://www.geany.org/manual/#id5> :)

Ok, didn't notice this setting before :-) However, for D (Djynn) I'd still keep the toggle comments function since it behaves differently. It's more of a flavour than additional functionality though. D toggles line comments if lines are selected (or the line at the caret if no selection) (without the tilde), but if text is selected that doesn't start and end with a '\n' that selection is wrapped with a block comment, and if a block comment is selected it toggles to uncommented. There is also a function for inserting Doxygen/Javadoc comments, and a strip comments function.

Cheers
Per

------------------------


Hi Jiri!

I definitely didn't want to say that PO is "better" or "done" or something like that - sorry if it sounded that way. I just wanted to describe what what were the ideas behind the plugin. Of course you can have a different vision and that's perfectly fine - the two plugins can coexist.

Ok, thanks! :-)
 

There are basically two options what to do about the plugins:

a. Keep them separate, each doing its project management in a different way. But in this case you should make a pull request to Geany to get the project open/close functions public otherwise nobody will use it because it won't compile with an official Geany release (you said you don't want to make the pull request but I'd suggest to reconsider your decision). I haven't for instance tried your plugin yet just because I'd have to modify Geany first to get your plugin compiled.

b. Find some common subset of the two plugins so there would be a plugins with a core part of the project management functionality and move the rest to a separate plugin(s). This is what I had in my mind when replying to your previous post but I guess our opinions about the core part are pretty different so right now (a) seems like a better option to me.

Personally I'd prefer the b-option, because I think it's the most beneficial in most ways. However, and as you say, given that the aims of the projects are in opposite directions, it would be quite difficult to find a common ground.

Seeing that PO works well with libraries such as glib and GTK+, I'll use it in the way you described, which is perfect since I'm working quite a lot with both on many of my projects.

 
Because the patterns from Project->Properties->File Patterns are passed to grep when you select "project" in the "Find in files" dialog and grep doesn't use regex for specifying which files to search using the --include comand-line parameter.

Also the glob patterns are used everywhere else in Geany for file specification so I didn't want to introduce something different.

Yes, I see. Personally I'm just a fan of regex, and so that made the decision for me ;-) I could change to glob though if it was of vital importance. An alternative would be to default to glob, and if the search string is wrapped in slashes, it's assumed to be regex instead.


OK, "heavyweight" wasn't the best word from me I guess. All the workspaces and sessions thing actually makes sense to me, I'm just not sure I want to add that to PO because this is pretty independent of the rest of PO functionality.

Np :-)


The meaning of "heavyweight" was in terms of the configuration needed to setup or update project. There are no extra config files in PO apart from the Geany project config files. Once you setup the patterns (or just keep the default blank value which is equivalent to * - then there's absolutely no extra configuration, you just create a new Geany project and you are done), there's no configuration needed in the future. If someone from the team gets crazy and reorganizes the whole project directories, you just press the refresh button and the new structure gets reloaded.

This same functionality can be accessed in D too, if you define the source directory with a regex pattern instead of glob, at present time. The difference is of course that there is one additional file per project. I don't think reading and parsing one text file per project is much load though. Any changes to the project are immediately written to the project file, and dynamically loaded directories are stored as only the directory and not the files in it. It takes extremely little resources to read and write these files, so the number of files does not account for making it "heavyweight" :-)


Well, my opinion is more isn't always better...

That is very true too! The golden mean is usually a good way, not too much, not too little.

 
If I'm interested only in C sources, I set *.c *.h as the file pattern in PO and don't have to care in which directories they are - in the sidebar I'll see just the directories containing the sources.

Same in D. With any changes of files, select "Reload workspace" in the popup menu. A function D doesn't have though is to load only files in open folders. At the moment, all files in a directory are loaded; it would be better to add files only when folders are opened.

 
Then there's the indexing thing - even if I don't work on all parts of the project, I often need some function from some other part of the project I'm not working on - by having it indexed I can just Ctrl-click the given function call and get directly to it and learn what it does. It's hard to tell in advance which parts of the project I'll need. Also you get autocompletion for all the symbols from the project.

A very practical function indeed.

 
In fact, for Geany for instance I add full sources of glib and gtk into the external directories so I get autocompletion for all the symbols in gtk and by ctrl-clicking a gtk function I get to its definition with the docstring so I can easily learn what it does.

Yes, this is excellent, I will surely use this too!

 
PO projects are designed so you basically don't have to touch them once you make them no matter who makes what changes in the project's file structure.

When I created the plugin I was working on this:


This is really cool! :-D

 
There were something over 2000 C++ source files (plus the same amount of headers), about 100 IDL files for CORBA IPC communication. The whole system consists of about 40 server applications and probably similar number of client applications, all communicating with each other using CORBA. The system has been evolved over 20 years by tens of companies. A lot of fun.

Yes, I can't imagine the amount of work to handle such numbers of source files.

 
Now when you are working on such a project, you are absolutely lost. If you need to fix a bug, you just don't know which file in which subsystem you'll need to edit. There's no way to "know" what's where because of the project size. You spend most time reading the code and trying to understand what it does. And having it indexed completely helps a lot. Also you need to regularly rebase your work on top of other work made by other companies and you aren't really in control of your sources.

At the time I found Geany the only editor with a reasonable amount of functions to handle a projects of this size. Other editors were either too simple or just kept rescanning all the sources all the time so CPU usage was 100% all the time.

Yes, Geany is certainly pure Gold for programmers!

 
Now of course that's a bit an extreme example but even if you want to start contributing to an existing open source project, you just don't know it and don't know in which subset of files you are interested in and basically want to see the sources, which corresponds to the "*.c" or whatever pattern.

True, PO would be better suited for such projects. D is definitely designed for projects that you know the files in.

I haven't touched Windows since 2007, but when I used to work in Windows there was an editor that extended MinGW, called Dev-C++, with a very simple and practical project manager that also generated makefiles automatically. Dev-C++ became like the blueprint for D when I began working on it. Since I exclusively use CMake for my projects, any autoconfiguration of makefiles becomes useless, and for anyone working with autotools it would be useless too. In fact D is entirely built with CMake, and that's why I've kept it a third party project - Geany, as I've understood, expect all its plugins to build with autotools (or waf, of which I know nothing).

 
Something in between - the current state definitely isn't frozen in any way, on the other hand, I don't want to "overfeature" the plugin. For instance, I could add e.g. file management things to the sidebar like creation/deletion/renaming of the files. On the other hand I believe these features should rather go to the file browser plugin. I think in a similar way regarding the workspaces/sessions as I feel it's something that doesn't quite belong to the plugin. The manual management of the tree is something which I don't want to add because I want to keep the project maintenance-free if its file structure changes.

Yes, I suppose sessions could be moved to a button similarly to the "Show Document List" button in the toolbar; and that way it could be separated from the project manager - since sessions are actually separate from projects.

Workspaces are part of the project manager however, and it's a concept used by many IDEs, and so not particularly unique to D. It is a very simple and practical feature. Projects in D require very little maintenance, depending on how they are constructed; they can be designed similar to PO, or more specific with picked files - in which case it could cause some maintenance sometimes.

 
It's easy to get sw bloated by adding more and more features so I'll always think twice before adding something new. But it doesn't mean no new feature will ever be added to the plugin.

It's the same for me, nothing is added that isn't required or useful. When I say "useful" it should be used on a regular basis, and not just that it could be useful, possibly - though it would be quite easy using the file browser instead.

 
No problem at all - I fully understand why you created the plugin and why it works for you. As I said, if I were you, I would just consider making the pull request to make the currently private functions you need public. Your use case makes sense and this way everybody will be able to use your plugin.

Thank you Jiri for your advice! I will make the pull request and update D. Perhaps you can check it out then. Also, good luck with your work! The space program seems really interesting!

Cheers,
Per