[Geany-Devel] [FT-plugins] Proposed "Features"

[Lex Trotman]

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