So the problem in Geany is we don't know the lexical scope of main, let alone use that to filter what names are visible?

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 - 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. Now, when you enable parsing of functions, you of course don't want tags defined in other functions than the one you are editing so these have to be excluded.
  2. For going to tag definition/declaration it's more or less like (1).
  3. 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). 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.
  4. For the symbol tree we should exclude local variables and function parameters.

Or in other words - the scope information is only used to detect how types are nested and what to show when . is typed, but the current scope (i.e. where the cursor is placed) isn't used for scope completion at all. We didn't do that because we had only tags at the global scope and it's not really easy to determine where you are (e.g. C++ namespaces can span multiple files, using namespace can be used etc.). But when function parsing is enabled, you can easily tell if you are inside a function of certain name or not and what tags are defined inside that function.

Nothing from the above is really hard to do (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:

  1. The easiest way to add local variables would be introducing a new entry for them to
    https://github.com/geany/geany/blob/d031d6f2fcb12e9670dade20fc9a657dedb5a5c2/src/tagmanager/tm_parser.h#L22
  2. We also might need to change the mappings to members of the above enum for some languages because this information is critical for scope completion to work correctly. This is why I suggested doing this #3032 (comment) to be able to do it independently of how the tags are shown in the sidebar (and to start working on this requires that all the parsers are in to avoid modifying the same code and introducing merge conflicts).
  3. The problem with (1) and (2) is that once we start modifying our mappings, we make the binary Geany tags files incompatible between Geany releases. This is why I suggested switching to the ctags file format because it doesn't contain the information about our internal mappings and then we can do whatever we want with the mappings. It doesn't mean that we should remove tag generation from Geany - we can still keep it but generate tags in the ctags format for users by default (and use the binary format for unit tests because there we want to see the mapped values).

I created new tag-manager label so expect a few pull requests with this label ;-).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.