@b4n Ping 2 :-)
Basically this is the API I currently propose. I believe it's quite nice also that it doesn't serve for LSP only but it could be used by other plugins too. I for instance noticed #3858 and if somebody wanted they could use this API for implementing a Tree-sitter backend.
What the API does is that it just simply disables the Geany functionality and makes the plugin do the work instead. This also reduces the amount of changes needed in Geany as Geany doesn't have to care what exactly the plugin does.
While in some cases it might be possible to reduce the number of checks whether the plugin implements certain feature, I didn't include it in this PR - such a refactoring can come later. Also, there are no docstrings, API bump etc. yet as the API may change based on the discussion here.
Now the symbol tree. I came to the conclusion that LSP symbols, which we know nothing about and which are only meant to be blindly displayed in the symbol tree without any processing, and TM symbols where we really know what they contain, are fundamentally incompatible and any form of unification will lead to this kind of ugly code everywhere:
if (tag->is_lsp)
//LSP symbol - do one thing
else
//TM symbol - do other thing
I tried this in the extra patches of #3850 and I don't like the result at all.
So for the symbol tree I propose this:
Thoughts?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.