[Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality

Colomban Wendling lists.ban at xxxxx
Sat Aug 27 10:13:28 UTC 2016


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


More information about the Devel mailing list