The problem (and it's not really a problem, it's just not done yet) is: 1. For normal autocompletion we currently include all tags
Actually this is _the_ __Problem__ (bold and capital P :-) and it makes autocomplete pretty much useless currently.
you want those because even if they refer to a tag nested in some type, this is what you might to want to get autocompleted
Sure as you say, currently without locals and parameters its mostly impossible to deduce scope (globals only) so dumping in everything and the kitchen sink is the only solution, but as you say that could be improved with newer parsers. But lexical scope is also needed because some pesky languages that are not C also have other names from the class definition visible within member functions (eg C++ member functions see all data members or Python "self" sees the class members). So if I understand you correctly the new parsers will give us a proper lexical scope (at least for function levels if not internal scopes) so we no longer need the hack of trying to align folds and declarations, and then it should be possible to reduce the noise a lot.
- For going to tag definition/declaration it's more or less like (1).
Well while we are at it, why not lump some more work on you, can we have a method of distinguishing overloads ;-) A single name is often declared and defined multiple times, eg `size()` is likely the most common name in C++, nearly everything has it (closely followed by `get()` and `set()`).
- For scope autocompletion the code should be adjusted that when determining variable type, it should first check the tags for variables defined in the current function and only afterwards look at global variable definitions (plus exclude variables defined in other functions).
Yes if the language says local names hide the global ones, but beware the C++ `::name` that sees the global one, or Julia `global x` that does the same.
Also we currently don't use inheritance information at all so you only get tags defined in the class for which the variable is declared but not from superclasses.
Nor (as I ranted above) do we see members defined in classes which are automagically visible in member functions (for C++, or with "self" for Python or Rust) before inheritance is even considered. And that of course means identifying if a function is a member function/method or just a "plain function".
- For the symbol tree we should exclude local variables and function parameters.
Yep, agreed.
Nothing from the above is really hard to do
The Clang guys would be surprised to hear that ;-)
(maybe traversing the inheritance tree might be a bit tricky but can be added later), it just has some consequences on some aspects of Geany that I'd like to address first:
Please note I am not just being annoying by bringing up the difficulties, exceptions, and issues above, I want to make sure all the weirdness of various languages are considered first so it can be implemented progressively, otherwise the first apparently simple solutions will block some of the more subtle later capabilities when you come to add them, and stuff will have to be undone or re-done leading to many massive PRs again, all with the `tag-manager` label :grin:
Maybe we should move this part of the discussion to a separate issue or github discussion rather than have it spread across several PRs like this that are only tangentially related.