I’ve been using Geany with patches whereby [typeahead search](https://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-view-set-s...) in the symbols list and in [TreeBrowser](http://plugins.geany.org/treebrowser.html) uses [`g_str_match_string`](https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g...) instead of simply matching by prefix.
Now, when I type “ba”, it finds not just `bar` but also `foo_bar` and `foo-bar`, etc. (not `FooBar` though).
It’s convenient.
The change itself is simple (all the heavy lifting is in GTK+/GLib), but I’m pretty sure this behavior cannot be made the default, as it might cause too many false positives, and would break habits.
What do you think of having such a feature as an option?
If suitable, what do you think its granularity should be? Should it be a checkbox for every tree view where it makes sense, like “Use fuzzy search in symbols list”, “Use fuzzy search in documents list” and so on?
(Also, I’m not sure it should be just [`g_str_match_string`](https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g...). Maybe typing “ba” should find `FooBar` as well. Maybe typing “fb” should find `foo_bar`, like in [Commander](http://plugins.geany.org/commander.html).)
There are a number of plugins that offer different ways of switching to open files. I'm not convinced that we should change the the sidebar behavior when there are alternatives.
@kugel- Yes; I use Commander for that. I’m mainly interested in the symbols list and TreeBrowser (which of course is outside Geany core). What do you think about the symbols list?
I don't think either the current way is useful, nor the proposed additional search method.
I have no specific objection to the alternative being implemented for symbols as a non default option. For documents, quite frankly if anyone has so many documents open that they need that, I think they need to re-evaluate their workflow :)
But neither is very useful when looking for a symbol or file that exists many times, such as a member like "length()" that exists on many classes or a file that exists in several directories. And those cases are the times I am more likely to actually want to search in the sidebar. Simple cases I can handle without.
@vfaronov perhaps, as an alternative, have a look at my quickswitch plugin (https://github.com/kugel-/peasy/blob/master/plugins/quickswitch.py). It opens a dialog (key-bindable) that allows switch by either file name, function or other symbol. It currently does prefix-matching as well, but I'd accept contributions to add other methods.
@elextr
But neither is very useful when looking for a symbol or file that exists many times, such as a member like "length()" that exists on many classes or a file that exists in several directories. And those cases are the times I am more likely to actually want to search in the sidebar.
Good point! This is [easy to do](https://github.com/vfaronov/geany/blob/0617c0e186de463e411b67ddb3331dbf8d519...) in my paradigm as well, because the symbols treeview already stores the `TMTag *` in one of its columns. A possible UI is to split the search key on the current filetype’s scope separator (like `.` for Python, `::` for C++), then match the last part against `tmtag->name` and the preceding parts against `tmtag->scope`. Which gives us:
[Similarly in TreeBrowser](https://github.com/vfaronov/geany-plugins/blob/0e77388160ce2796fd2de771e0c26...).
This only distinguishes the innermost level of nesting, so in the above example, `Foo.Meta.baz` would be matched by all of `f.b`, `f.m.b`, `m-f.b`. But I think this should often be enough.
Is this what you had in mind?
------
Anyway I realized that `g_str_match_string` is in GLib since 2.40, while Geany only requires GLib >= 2.32. So this will have to wait until Geany bumps its GLib dependency (if ever). Or maybe it’s a good excuse to write a custom matching function handling BumpyCase as well.
A possible UI is to split the search key on the current filetype’s scope separator (like . for Python, :: for C++), then match the last part against tmtag->name and the preceding parts against tmtag->scope.
So it would be neccessary to type `Classname::length` to find it?
Thats possibly useful, but just manually duplicates what `right click->goto symbol definition` does. Ok it helps if I don't have a use of `length` in front of me, but then why would I be searching for it?
For the Treebrowser, its a plugin, so I don't care what you do, I think the idea of having a second rate filemanager embedded in an IDE is silly and don't use it. You should open a linked issue on geany-plugins for discussions about it, rather than here.
Attempts to keep the Glib dependency low will probably cease (for a while) when GTK2 is dropped, but thats still far into the future.
So it would be neccessary to type `Classname::length` to find it?
No, just `c::l` — assuming there are no other symbols matching that, or few enough that you are willing to walk over them by pressing the Down key.
Ok it helps if I don't have a use of `length` in front of me, but then why would I be searching for it?
I don’t know. You suggested yourself that there are cases when you are “likely to actually want to search in the sidebar”.
Myself, I think I more often browse the symbols list than use go-to, but it’s hard to explain why. I just know I need a particular symbol, I know it’s in this file, but I don’t know on which line, and the symbols list is the easiest way to find it.
This works now, I think https://github.com/geany/geany/pull/3055 implemented it.
Closed #1466 as completed.
github-comments@lists.geany.org