Thomas, #1195, maybe read that and try again.
Cheers Lex On 27 August 2016 at 06:34, Thomas Martitz <ku...@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@lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/devel _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel