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