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

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

[...]
>
> Nobody suggested to encode specific language semantics into Geany. I'm
> suggesting TM should become more generic, i.e. TMTag should transport as
> much information as required (even if some of it can't be provided by ctags
> but only some plugins).

But as noted above you need the language specific knowledge to USE the
data too.  A generic TM just can't answer the question.  There is no
problem improving TM, but at some point the question is just too
language specific for a geenric TM to handle.  So the question becomes
"who knows when that is?" and only the language specific plugin knows
that TM doesn't know what its doing.  The plugin has to be asked
first, if it then defers to TM, fine.

> Most of the issues don't apply to just C++ but so many other languages as
> well (e.g. Java). All of them can be improved more easily, not just C++, if
> Geany can offer a powerful framework for that. But the framework Matthew
> proposed is not powerful to me. It just evades the current problems simply
> by moving Geany's deficiencies to the plugin space.

Because to make Geany able to answer the two questions I asked above
it must have language specific knowledge coded into it (well at least
I know of no other languages with ADL and neither does wikipedia
https://en.wikipedia.org/wiki/Argument-dependent_name_lookup).

Certainly some issues don't belong to C++ alone, no language has local
declarations and scopes handled by TM, and that would help, but again
the specifics of scopes, and lookups is language specific, so you need
language specific code in Geany.

Cheers
Lex

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