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@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Reply via email to