Filter symbols in the Symbol List (new feature) #2657
Conversation
This patch fixes symbol tree construction when geany#2657 is applied. When a filter for tags is used for the symbol tree, it may happen that parent tags in the symbol tree are removed because they don't match the filter. Such tags are still visualised nicely by the symbol tree which shows these tags with full scope like MissingStruct::some_member However, the current code doesn't expect that it may happen that MissingStruct re-appears in the results when filter is deleted. In such case 'some_member' isn't re-parented under MissingStruct and stays displayed in the above format. This patch simply removes tags like 'MissingStruct::some_member' for which parent hasn't been constructed yet from the symbol tree and re-adds them in the "insertion pass" for the symbol tree update code. The only change this patch does is that it replaces if (parent_name && ! g_hash_table_lookup(parents_table, parent_name)) parent_name = NULL; with if (!tm_tags_equal(tag, found)) cont = tree_store_remove_row(store, &iter); else { The rest is just indentation after the 'else'.
This patch fixes symbol tree construction when geany#2657 is applied. When a filter for tags is used for the symbol tree, it may happen that parent tags in the symbol tree are removed because they don't match the filter. Such tags are still visualised nicely by the symbol tree which shows these tags with full scope like MissingStruct::some_member However, the current code doesn't expect that it may happen that MissingStruct re-appears in the results when filter is deleted. In such case 'some_member' isn't re-parented under MissingStruct and stays displayed in the above format. This patch simply removes tags like 'MissingStruct::some_member' for which parent hasn't been constructed yet from the symbol tree and re-adds them in the "insertion pass" for the symbol tree update code. The only change this patch does is that it replaces if (parent_name && ! g_hash_table_lookup(parents_table, parent_name)) parent_name = NULL; with if (parent_name && ! g_hash_table_lookup(parents_table, parent_name)) cont = tree_store_remove_row(store, &iter); else { The rest is just indentation after the 'else'.
|
@dmitryunruh I'd love to see this feature in Geany! @eht16 @elextr What do you think about this feature? Personally I'd love to be able to filter the symbol tree in a similar way like the plugins list. Also, the patch is quite tiny and limited in scope so it shouldn't introduce any problems. I had a look at the patch and apart from some style changes it seems to do the right thing in principle (I could do a proper review if there's an interest in this feature). The searchbar is currently placed directly above the symbol tree without anything and it might look better if it were placed inside a panel or something so there's something around it. It might also be better to perform case-insensitive filtering, but these are just minor points. I created #3015 to address a minor problem where the tree didn't get re-constructed right after cancelling the search. |
|
s/I created #3015 to/I created #3050 to/ :) To the topic:
I see why the update on notebook tab change is necessary; the symbol filter text is static and applies to all documents. I think it would be even better to have filters per document, otherwise it could be confusing if I switch to another document and suddenly the symbol list is empty. After wondering about it, the user will probably realize it's because of the still set filter and then will clear the filter. |
That shouldn't be a problem - update of the symbol tree is performed every time the document is re-parsed while typing and if the machine is too slow, editing the document itself would be a much bigger problem already.
Good point, I didn't think about that.
What about a "lazy" solution to clear the filter automatically on a tab change? |
|
One more nice thing to have after playing with it would be to highlight the first item in the tree after pressing enter (but not confirming it so arrows can be used to select the right item).
Same sad story here with the 8-core ARM Mac :-). |
Sigh, boys and their toys 😄
Then the user would be confused on switching back to the original tab to find their filter gone? |
The question is whether not to even clear it after selecting an item in the symbol tree. The use case for this feature I had in mind was to just get quickly to the right symbol in the tree and navigate to it and not really having the tree filtered permanently (and having to manually clear it later). |
Hmm, I tried it but it's strange. So if it's on a per-document basis, the filter string should probably go to |
Ahh, so its a search facility, not really a filter. Would be good, the current search is useless unless you happen to want the first occurrence. So as a search then yeah it should go away on loss of focus really. |
But it turned out to be weird when I tried it and it really should behave as a (permanent until cleared) filter. Some things I discovered in addition:
in the symbol tree because Sigh, I thought this would be a nice little patch, quick to apply, and here it comes again :-). |
Or, to avoid making the code more complicated in the tree update function, just to remove everything from the tree when filter changes and get the whole tree re-populated. The main purpose of the complicated code in the symbol tree update function is to avoid scrolling when a change is made in editor but when applying filter, this will happen anyway because the changes in the tree are big. |
|
JFTR, I didn't mean to suggest it should be a per-document filter. Only that it would maybe create the most comfortable solution but also with the most effort needed. Getting back to @techee's first idea of this feature: when we want tojust jump to the first match of a symbol, it might be enough to enable GTK's treeview search feature (where a little text input field pos up automagically and filters the tree, https://docs.gtk.org/gtk3/method.TreeView.set_enable_search.html). In case someone wants to try, there might be signal handlers on the symbol list to switch focus to the editing widget on any keypress, at least it feels like this. |
|
@eth16 if its only really a search facility and goes away as soon as something is selected, or the little text box cleared, or the tab switched then agree there is no need for it to be per-document. But first match is not very useful for languages that are not C. C is ok because everything is distinguished by name and there is no overloading but all modern languages allow and even encourage multiple occurrences of the same name. And anyway I think So unless any change improves the capability for multiple search by either having a "next" or by filtering it won't add much. |
|
I created #3055 with some of the improvements discussed here. |
|
Closed by the merge of #3055. |
It adds an entry field at the top of the symbol list to filter this list.
The text of the entry field divides into parts with a space symbol. A symbol of the symbol list (tag) must contain each of these parts to be shown in the filtered list. Filtering applies immediately during changing the text of the entry field.