I think we all agree that help of language-specific plugins is desired/required. No need to restate "we need language specific support" all the time.
We just disagree on how the language-specific knowledge is transported to Geany, other plugins and the user.
Well, I read your previous comments such as "But *just* the data, don't offload very specific use cases onto them" (and to some extent this one too) as saying that all the plugin has to do is return some data (tags) and Geany will take it from there and all I was doing was making sure it was clear that its unlikely that Geany will be able to "take it from there" in any meaningful way, based purely on data, without filetype specific knowledge inside Geany.
Geany must ask the plugin for the answer for each element of functionality the plugin provides. This means that those elements have indeed simply moved "Geany's deficiencies to the plugin space" as you put it. This is good and necessary.
Of course moving the problem to plugin space doesn't mean the plugin can't use Geany facilities where their capabilities fit the requirement. But we should not try to expand Geany to handle all types of functionality.
Like your TM query interface, the plugins should answer the questions like "whats the autocomplete here", "what calltips are relevant here" with a flat list of data relevant to the question.
The only place all the symbols should be returned is for the display in the symbol tree, and for that use I'll defer to Colomban's suggestion to provide TMTag structures, not for the plugin to access TM.
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel