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

[Thomas Martitz]

Am 31.08.2016 um 13:23 schrieb Lex Trotman:
> [...]
>>> But
>>> to be able to do 2) and 3) accurately needs more knowledge of each
>>> language semantics than is currently available in Geany or tagmanager.
>>
>> That's right. But it doesn't mean the features should be *entirely* moved
>> into plugin space. TM should be improved to be able to hold sufficient
>> information, and plugins should help by providing that data. But *just* the
>> data, don't offload very specific use cases onto them, this will make us
>> less flexible in the long run. If Geany has the data, we can implement new
>> features inside Geany or non-ft-plugins. Otherwise we would have to modify
>> every single ft-plugin for new features and exclude non-ft-plugins.
> The problem isn't having the data, its what you do with the data.  To
> repeat two C++ examples I posted on IRC:
>
> namespace foo {
> struct A { int a=1; int b=2; };
> void f(A& anA, int inc){ anA.a+= inc; }
> };
>
> foo::A anA;
> std::vector<foo::A> someAs;
>
> The current Geany correctly parses this and shows the correct thing in
> the symbols pane, so it has the data, it doesn't even need to use a
> plugin for the data.
>
> int i = someAs[1]. // Ok TM show me whatcha got, whats legal here?
>
> Answer: a and b because the vector returns a reference to its template
> parameter, here foo::A that has members a and b, you have to expand
> the template to find the answer.  This is used all over the standard
> library.
>
> f( // no calltip because no f is defined in this namespace
> f(anA, // so thats the calltip now?
>
> Answer: void foo::f(A& anA, int inc) even though f() is in namespace
> foo, because the first argument is type A which is declared in
> namespace foo, ADL then will find foo::f().  This is also used in the
> standard library and many other libraries.
>
> Both of these are C++ specific semantics, (types generated by template
> instantiation and argument dependent lookup).  I don't believe TM
> should be be expanded to include such knowledge.
>

Why not? TM could have separate tags for each known template instance 
and know which of these applies to someAs, based on information provided 
by a ft-plugin. Then the rest would work.

Besides, template instantiation requires compiling the units IIUC, which 
is probably not gonna happen ever? At least not on every keystroke as 
done currently.

Best regards.