@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/0617c0e186de463e411b67ddb3331dbf8d519daa/src/sidebar.c#L128-L148) 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/0e77388160ce2796fd2de771e0c26d8f95bd0210/treebrowser/src/treebrowser.c#L1674-L1691). 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 or view it on GitHub: https://github.com/geany/geany/issues/1466#issuecomment-297098124
