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

[Lex Trotman]

Thomas,

#1195, maybe read that and try again.

Cheers
Lex

On 27 August 2016 at 06:34, Thomas Martitz <kugel at rockbox.org> wrote:
> 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.
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel