Before I look too deep: So I understand this only affects the sorting but does not add tags*?

Yes (except for the header tags themselves for every include, see below).

*: the new tm_tag_header_t only says "foo.h is included" so that we can later lookup foo.h and import tags from that file, right? So not a real tag but more of a pointer to a TMSourceFile?

Adding to @kugel- question, my understanding is that it only looks up include files that are open or loaded via tagfiles, it won't open any extra files, is that right?

For every include in the parsed file such as

#include <some_path/some_header.h>

the header tag generates tag whose name is

some_path/some_header.h

This is completely independent of what files we have open, it can be whatever file name. It's up to us to match this file name to the open TMSourceFile files. This is what the first patch serves for - it maintains a hash table

file_name -> List<TMSourceFile>

so we can take the header tag and quickly look up the corresponding TMSourceFile. The List is there because there may be multiple identically named files opened from different paths - it's hard to make any guess about the paths since we don't know which directories are searched for the includes by the build system. When we don't find any corresponding TMSourceFile, the file isn't open in Geany and we don't do anything for that include. The header_tag -> TMSourceFile lookup happens dynamically when performing autocompletion and it isn't stored anywhere.

I previously understood that it adds tags for (private?) members that are declared in class declarations so that they can be autocompleted in the corresponding source file but not in other source files.

No, it doesn't (and didn't) add any tags, it serves for sorting purposes only but in two different situations where in (2) it affects what results the user gets:

Sorting the tags in non-scope autocompletion popup - this just affects the order in which the user sees the tags where I think it makes sense to see tags from included files before other project files.
Sorting the candidate tags which are searched for members in scope autocompletion. Let's say the user has just written

name.

and expects we show a list of name members. Some tag names are very common and for instance in this case, I can imagine many classes have the name member possibly each of a different type (and different members) so it's important we pick the right name tag. When we sort all the name tags so we first check the tags from the header file, we have a good chance of showing the right members than some name from a totally different class unrelated to the current file.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.