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:
1. 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. 2. 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.