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

Thomas Martitz kugel at xxxxx
Fri Aug 26 20:34:58 UTC 2016

Uhm, where did this thread start? Who are you replying to?

Am 26.08.2016 um 09:13 schrieb Lex Trotman:
> Not sure I agree that Github is bad for *development* discussions, for
> users, sure, the ML is likely to find the audience better, but most
> developers will also be githubians. Also github supports markup that
> mail doesn't.  But anyway lets try mailing it in for this issue, and
> see how it goes.
> But everybody, please DO NOT EDIT THE SUBJECT LINE IF ON THREAD some
> mail agents thread by subject, and DO NOT REPLY IF YOU WANT ANOTHER
> THREAD some mail agents thread by previous ID.  We should not dictate
> what sort of mail agent people must use to contribute, please respect
> individual or enforced choices and follow this procedure (codebrainz
> this should go on the issue guidelines).
> I agree with the approach in general, but for some major items (about
> the process):
>> rather than endless discussions we let the code do a lot of the talking
> No, not yet, we need to agree what we are going to code.  This is a
> major change to Geany's design, and it should be designed, not just
> jump into coding it.  Geany suffers from too much "heres some code I
> made earlier".
> codebrainz, you clearly have some design in mind, please *describe*
> (not code) it to get the ball rolling.

I'm not even sure what the thread is about. Is it replacing ctags 
through plugins or filetype specific plugins? The latter is much more 
than just tags.

For the former, I can only say that we must avoid trying to take 
shortcut by adding APIs like "allow a plugin to add its own tags to the 
sidebar" or "add words to the autocompletion dialog". This is use-case 
specific, and is going to be troublesome if multiple, competing plugins 
are at play (not necessarily targeting the same language).

tl;dr: We want interfaces where plugins can provide tags/symbols to 
Geany, so that Geany can use those to build the 
sidebar/autocompletion/etc. as it sees fit. Giving the option to 
override the sidebar will just result in every plugin doing it 
differently (and some of them incorrectly), and as a result yield a poor 
user interface.

Full story:
What we really want is methods that allow plugins to provide the *data* 
that Geany uses for sidebar/autocomplete/whatever. That means, plugins 
should be able to add to the tags storage (tagmanager or otherwise). 
Then Geany can use these tags, merge multiple tag sources (=plugins) 
together and show a consistent user interface.

This is somewhat similar to the proxy plugin. By adding an interface to 
make Geany learn about the proxied plugins, we avoid stuff like "allow a 
plugin to override the PM dialog" which would just result in plugins 
breaking the conistnetn user interface. Instead, we achieved a mechanism 
where Geany can show plugins that it can't load itself in the same UI as 
traditional plugins, making this thing just work seemlessly.

This should be the design goal when it comes to plugin wanting their own 
tag management. Geany must be in the loop so that it can multiplex 
between competing plugins and its own functionality, and still present 
the whole thing in a consistent manner to the user.

Best regards.

More information about the Devel mailing list