@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 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.

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.

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