There's one thing I noticed - I think you should also add mappings for types that can appear as parents of other symbols. For instance, because of the missing `oop` package mapping, the symbol tree doesn't generate it in the hierarchy and the bottom part of the screenshot below shows just flat symbol list instead of a proper tree.
That's something that's confusing me. There IS an `oop` package mapping, it's not missing (if I understood correctly); and also an oop/enum_t, and an oop/other_class/s_member and oop/other_class/u_member, so why do their members appear outside of the tree hierarchy? Seems like a bug.
![Captura de pantalla_2024-11-20_01-26-02](https://github.com/user-attachments/assets/2af5386a-844c-46d4-8ed1-16b08c5a2...)
All of `package oop` (`"package"` → `tm_tag_package_t`), `typedef ... enum_t` (`"typedef"` (not "enum") → `tm_tag_typedef_t`), `typedef ... struct_t` (same), `typedef ... union_t` (same), `struct ... s_member` (`"struct"` → `tm_tag_struct_t`), `union ... u_member` (same), and `enum ... e_member` (`"enum"` → `tm_tag_enum_t`) are mapped and labelled, and appear in the symbol list. But the members don't appear inside. The only one that seems to work is the enum member inside the class for some reason.
So it seems to be a bug. Not sure if it's in Geany or in ctags. But it doesn't seem to be related to the changes I made. (Would be nice if it could be fixed though, by me or someone else.)
While doing so, I noticed a couple of issues/bugs in ctags (I think), but those should be fixed in ctags.
If you decide to update the ctags parsers, you should get it merged to ctags first and then open a PR in Geany with the change.
Yes, that's what I meant. That it needed to be fixed it in the ctags project.