Still thinking a bit about the symbol tree - it would be nice not to have a separate tab that users have to switch to. What about:
- allowing the plugin to access the GtkTreeView of the symbol tree so it can put whatever it wants there
Could the extension be called once (per document, and probably when changing filetype) to create the TreeView? This could allow the extension answer `GtkWidget *create_tag_view(GeanyDocument, …)`, returning a `GtkTreeView` with whatever renderers and model it wants.
- have some "filter-modified" event so the plugin knows when the filter changed
If we reimplement the feature using `GtkTreeModelFilter` instead of the custom code from d3ded11ad2c8caeb0dd4aef2fcff517c5672b2e2, and require the model in the view to be a filter, we could probably just call [`refilter()`](https://docs.gtk.org/gtk3/method.TreeModelFilter.refilter.html) and give access to the entry data somehow.
Or require the plugin to manually listen to `changed` itself like we do.
In any case, the plugin need to have access to the filter value, so either have an event like you said, or a mean to access it at will.
[…] In theory this should be all it's needed but something else may appear during implementation. How does it sound?
Good if it's not too hard to implement the details like activating a row, navigating them an whatnot, but I guess we don't have much custom stuff apart knowing where to go, which is exactly what the extension *would* know how to do.