[Geany-Devel] Devel Digest, Vol 93, Issue 5

[Per Löwgren]

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:
>
> https://en.wikipedia.org/wiki/SCOS_2000
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20151220/82dd32e6/attachment-0001.html>