Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I'm not a huge fan of this. I use plugins that depend on tagmanager, therefore I cannot use LSP.
That's not how it works - TM is still active and running in parallel to the LSP server. It's just the individual GUI features you see that get switched to LSP. You can even combine TM with LSP - in the plugin I made all the individual features possible to disable so you can still use the TM counterparts.
I think this going the wrong direction. Now, for example, when "goto definition" is requested we start some IPC or network action which can block and/or fail, and this is going to be a nightmare to debug. We don't know beforehand what will happen, like if the language server even provides any useful information.
Well, that's how LSP works - if you don't like it, just don't use LSP. I added the possibility to log the full JSON communication either to stdout or to a log file and also the stderr of individual servers and the whole thing is quite easy to debug. Ultimately it isn't Geany's responsibility to debug the IPC communication with the server, it's the plugin's maintainer's (mine) responsibility.
Instead I think we should use LSP to augment tagmanager so that we have all the needed bits within our problem space when "goto definition" is triggered. Then we can reason about the result. If tagmanager data store is not suitable we should make the necessary modifications there to make LSP realistic.
I have absolutely no idea what you mean by this. What do you mean by "reason about the result"? The LSP server just returns the file name and line number and I don't know what "reasoning" you want to do about it.
If you imagine that you somehow get more information about individual symbols and then you implement some advanced logic on top of that then no, this is not possible - LSP won't give you more information than we currently have. For instance for document symbols it offers less info using the (documentSymbol request) than we have in TM - it just gives you enough information for a single GUI feature, in this case to display the symbols in the symbol tree. The whole idea of LSP is to behave as a black box completely hiding all the details from editors behind a single interface.
Last but not least, I think we should have a unified API towards plugins so that they can work with tags and symbols regardless of LSP or tagmanager (or a combination).
Plugins can keep using the symbols from the tag manager - LSP is not meant to be used this way and symbols from LSP won't be exposed to plugins (and again, it wouldn't make sense because TM gives you more info than what you can obtain from LSP using its API).
I really suggest having a look at the LSP specification here
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification
to understand what it's all about and how it's supposed to be used by editors and what you can expect from it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.