Le 27/08/2016 à 06:17, Lex Trotman a écrit :
[...]
Allow plugins to provide the symbols for the tagbar tree...
Do you mean the symbols pane? Or do you mean to inject symbols into tagmanager so all existing functionality also sees them?
I mean something more like where Geany tells the plugin it wants to update the symbol tree and so asks the plugins for the symbols to show. It's sounding (from Jiří and Thomas) that using TM as a conveyance mechanism for this may make some sense.
Possibly, so long as its flexible enough to be able to support the particular language symbol and scope structures, then allowing existing code to keep accessing the symbols in the same manner has advantages.
From what I gathered, using TM for he symbol pane would be just fine for
everybody. It's just providing a set of data describing the items, and if the tags are only used for that they only require some minimal set of data:
* name * scope * kind (function, variable, etc.) * optionally argument list and return type. * optionally anything else we don't yet use.
For auto-completion, it might not be that simple at all. Because being generic code, it might not be able to handle every language's specific syntax where it should show scope completion, calltips, etc. For calltips, imagine a language that don't use parentheses (or anything at all) for specifying argument lists: how will we know we need to show it? Even "just" shell scripts fall into this. So there might at least be an need to trigger some of those things in Geany form a plugin, but probably more generically provide means to override Geany when it can't be taught to behave right.
Maybe it could be as simple as plugins providing tags and telling Geany to complete/scope complete/show calltips at some point, but it might be slightly too optimistic, because no matter what the generic code will always have worse knowledge than the specific one.
But, ATM it doesn't support lexical scope IIUC, the TM experts should comment.
This is IMO a kind of non-issue you keep on bringing :) I mean, yes, there's no such concept yet, but I can't seem to find any reason why it couldn't be like any other tag. A tag that is ignored for anything but resolving the scope, which from the top of my head just means to ignore it when searching for names.
Yes, it would require altering the existing code, but it hardly seem a blocker to me.
I remember that. Most likely something along those lines will be a good way to load the plugins, though it might require to be a bit more advanced to deal with plugin lifetimes and other stuff.
Yes, and might be even simpler if it can take advantage of any of the new plugin capabilities. IIRC filetypes are never unloaded after loading, so the plugins would have to be the same. Possibly they shouldn't even show in the PM, or show as not user removable.
IMO this is kind of unrelated to the issue at hand. Yeah it *might* be nice to auto-load/auto-unload filetype plugins when staring using the filetype, but it's much more of a toy than an actual important design piece if it loads normal plugins (which it probably should, unless proven otherwise). My point is that it adds extra complexity to an already complex-enough issue, seem kinda orthogonal, and only removes the need to manually check a plugin in the PM dialog.
And it's even a complex issue, because you still need to let the users chose not to load those plugins if they don't want them, etc.
Regards, Colomban