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

[Thomas Martitz]

Am 01.09.2016 um 08:05 schrieb 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?

vector<int> and vector<A>, with scope being std (I think trailing scope 
delimiters are not saved in the scope string of TMTag, just intermediate 
ones).

>
>
>>> 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.


Ideally the header which defines std::vector<A> would be found (and 
maybe opened) right? Currently this isn't possible with TMTag (as 
var_type can only contain either vector<A> or vector<int>) but it 
shouldn't be too hard to make it work. Like adding a generic_type field 
which is set for each template instance (containing vector<A>), then 
instead of looking up the decl of generic_type if it's not NULL, 
otherwise var_type.

Of course, the TMTags associated with vector<A> and vector<int> would 
have to provided by the ft-plugin too (maybe there needs to be a new 
TMTagType for vector<A> too).

>
>>> 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.
>

So that means

1) My plugin contains code specifically for each known ft-plugin (i.e. 
not the plugin API)
2) There needs to be a shared library which my plugin can use to call 
into the other plugin
3) My plugin needs to know if and when to ask a ft-plugin

This is not acceptable. Or are you saying Geany could provide a wrapper 
for this as Matthew suggested? That might be workable.

Best regards.