I just noticed one more thing - even symbol names obtained from LSP aren't guaranteed to be just plain names - consider for instance the Mutex source from the Go system library:

Here you have the functions working on top of the Mutex type prefixed with (*Mutex) while with our TMTags we'd have this in scope (the gopls server's representation is more idiomatic for go than having the methods scoped within the Mutex type). Similarly, pylsp generates what we call "local" tags (for variables inside functions) but we have no indication from the LSP server that these tags are local (which we'd need for correct autocompletion). On the other hand, clangd doesn't provide local symbols at all unlike our TM cxx parser.

So I think we just can't make any assumptions regarding what we obtain from the server - the "right" and intended way to use the interface is just to blindly display what the server returns. This also means we cannot stuff the info from the LSP into TMTags because we just don't know what the server returns.

So if we want to unify TMTags with what is returned from LSP servers, we have to do it the other way round - within TMTags introduce fields like:

display_name - the name that will be displayed in the symbol tree (corresponds to name in LSP)
display_detail - the name that will be shown as a calltip (corresponds to detail in LSP)
display_icon - the icon to display - here I'd just suggest avoiding Geany having to care about the symbol kind representations in LSP (there are two - one for autocompletion, one for symbol tree and workspace symbols and the values are different) and let the LSP plugin return the right icon for Geany to display
scope - we could keep this one for LSP symbols. What I did for the symbol tree is that I generated it from the children information of the symbols and it seems to work alright.

We could generate these for TM tags inside TM and the parts of Geany showing these in various UIs like the symbol tree or the autocompletion popup could just read these fields and ignore the rest of the tags.

Now my question is - should plugins really have access to these LSP symbols? I somehow can't imagine anything they could use these for apart from showing them in some different kind of UI - they'd run into the same kind of problems interpreting them as Geany would.

Back to the API - should it be specific for the LSP usage or more generic so it can be used by other plugins? I called the file Lsp but in reality, the current interface could serve to any other plugin that e.g. wants to provide its own autocompletion support - there's nothing LSP-specific about it. So it's more like ExternalFunctionalityProvider which disables Geany's handling of certain features and delegates them to an external entity.

On the other hand, the API could also be really LSP-specific where we require LSP to be present and have it somehow deeply integrated into Geany - but I don't see much use for such deep integration myself especially when we still want to keep using the TM.

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