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

[Lex Trotman]

On 1 September 2016 at 15:08, Thomas Martitz <kugel at rockbox.org> wrote:
> Am 31.08.2016 um 17:26 schrieb 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.
>
>
> Here we disagree. I think it is possible to extent TM/Geany sufficiently to
> encode this information in generic ways. As an example, template
> instantiation yields different types. TM could tread them as different
> types. Any variable will be of one of the types, so calltips would just
> work.

It is of course always "possible", after all its a mere matter of programming :)

And of course an instantiated class template is just a type, but what
is the name of std::vector<int> and std::vector<A> so it can be looked
up?


>
>>
>> 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.
>
>
> To me this is not good because it makes it impossible to use the information
> for other use cases in Geany or other plugins.
>
> For example, I want to keep my quickswitch plugin that allows me to jump to
> arbitrary tags, even if a ft-plugin is doing all the hard work to parse
> them.
>

Good point, the FT-Plugin API needs functions for goto declaration and
goto definition.  Unlike TM, the plugin can take language and scope
rules into account when it answers, so you get the right declaration,
continuing the theme above, where would you go to find the declaration
of std::vector<int> ?

Certainly not the line:

std::vector<int> list_of_ints;

thats the declaration of `list_of_ints` but thats the only place that
`std::vector<int>` exists in the code.

>>
>> 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.
>
>
> My TM query interface wants to return all matching tags, including those
> found by ft-plugins. Can this be done?

Only if your query plugin queries the FT plugin.


>
> Best regards
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel