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
On Sat, 4 Oct 2008 11:00:13 -0700 "Conrad Steenberg" conrad.steenberg@caltech.edu wrote:
- 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?
I should have been clearer. The patch 'parses' the parent name in the GeanySymbol::str field e.g. "Parent" from "Parent::Child". Line 458 of symbols.c shows:
symbol->str = g_strconcat(tag->atts.entry.scope, cosep, utf8_name, NULL);
So it would be cleaner and safer to remove the old GeanySymbol code and let the tree creation code read tag->atts.entry.scope instead.
...
- 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")
OK. Possibly that bug is already fixed in ctags, haven't checked yet.
- 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.
BTW I meant the 'scope' field, there's no parent field.
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 :-)
Thanks for writing the patch ;-) It's great for the filetypes I use such as C/C++. I'll work on these changes in the branch [1] and merge them to the trunk after 0.15 is released.
Regards, Nick
[1]: https://geany.svn.sourceforge.net/svnroot/geany/branches/symbol-tree