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

[Lex Trotman]

On 27 August 2016 at 20:13, Colomban Wendling
<lists.ban at herbesfolles.org> wrote:
> 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.
>

Yes, the pane is probably the simplest use of the data.

>
> 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.

Yes, that would be the best, for the "languages that are C" let Geany
do it, and let the plugins do it for the rest.

>
> 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.

Yes, languages will always be finding different ways of doing stuff
that is different, so long as the filetype specific plugin can do away
with the built-in then it can all be supported.

>
>> 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 :)

Well, until this point nobody has actually put a concrete proposal for
how to handle it :)

> 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.
>

Neat, a pseudo-tag representing the lexical scope, and it can have
pseudo-tags for enclosing scopes as parents and they can have named
scopes for the enclosing function.  That sounds like a plan.  And if
some language has something excruciatingly smart there can be
different types of pseudo-tags.

> Yes, it would require altering the existing code, but it hardly seem a
> blocker to me.

Only until an actual solution was proposed :-D

>
>>> 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.

Well, my point of raising it was to point out it wasn't an issue to be
able to activate filetype plugins automatically, my first post said
"but it actually was so simple that it doesn't matter."


>
> 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.

Just set the keys to an empty value in your user filetype file, like
anything else there is controlled.

Cheers
Lex

>
> Regards,
> Colomban
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel