Hi
Nick T (ntrel) suggested we move discussion of a symbol tree patch to the list - https://sourceforge.net/tracker/index.php?func=detail&aid=2083110&gr...
Comment By: Nick Treleaven (ntrel) Date: 2008-10-03 15:17
Message: I have some ideas to make the code more straightforward and robust:
- Replace the GeanySymbol list with a TMTag list. This avoids having to
parse the parent name, avoiding possible bugs.
I'm not exactly sure what you mean - I thought that parsing the symbol names was the only way to determine symbol tree structure?
E.g. given a list of symbols
B.c.d A A.b B.c B
We can construct a tree: A |_ b B |_c |_d
The information on the tag type is simply used to determine the icon/type to use in the tree.
- Sort the tags by appearance before adding to the tree model. This
ensures that parent items are added before children, and we can remove all the complex 'skipped' code. The model can then be sorted after all entries have been added (for the 'sort by name' case).
Yes, presorting sounds like a good idea to avoid modifying the list of symbols. FWIW the current logic is to move a symbol to the end of the list if its parent cannot be found.
Note that the 'skipped' list is actually not used in the current version of the patch - it was there to catch errors caused by a bug in the the C++ tag generator (nested namespaces, see bug "[ 2141317 ] C++ nested namespace tags created incorrectly")
- Instead of looking for children for certain tags (e.g. class, etc),
just see if the TMTag struct has a parent field. This should be much more flexible for filetypes that overload e.g. the tm_tag_class_t fields to mean something else.
I'm happy to work on these changes over time. If you want to discuss them, the geany-devel list might be better than here.
Of course you're welcome to do that - I'm simply happy to have the feature since it really helps navigating complex code.
Thanks again for your and all the other geany developers' work :-)
Cheers, Conrad