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.png (view on web)

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.

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