Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
You seem to misunderstand my point. I'm not at all against LSP, quite the opposite. I like LSP because it seems to be industry standard by now with lots of server-implementations (of varying quality) that loosens our "ctags lock-in".
Yet you don't seem to get the point of LSP. The point is to delegate all the "smart" features to the server and let it do the hard work and then only display the results or perform the edits in the document that you obtain from the server. Basically no processing on the client side.
I just don't like this proposal because it "hacks" LSP support into each relevant use case instead of augmenting the existing TM infrastructure with LSP information. It adds individual band-aids for each use case and leaves behind other uses of the TM infrastructure (in other plugins). It's OK to get familiar with LSP and have something to showcase "geany-on-lsp" but it's not something that I comfortably support going forward.
Once again, this is how LSP works - if you want an autocomplete list, you ask the server to provide it for you using the completion request:
And you have to do it at the point where it makes sense and disable the TM's autocompletion because you don't want two autocompletions in parallels.
Similarly, if you want go to symbol definition/declaration, you use
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_declaration
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_definition
and the server returns the right location.
When you want to get information for colorization of types or other symbols, you use
For calltips you call
For symbol tree, you call
And so on.
LSP servers ought to provide the symbols for files via DocumentSymbol or SymbolInformation. That should all be needed to build up a TMTags array attached to TMSourceFiles (without actually parsing via ctags) [1]. Sure, an LSP might not provide all the bits we want, but as @elextr said that may be the case with poor ctags parsers as well, or this very server instance is not worth asking anyway.
You can surely do that but the question is why would you do that. You get identical (or worse) info regarding individual symbols than from TM but enough for the symbol tree (which is the purpose of this particular LSP call). But you can't derive any extra info from it for the "smart" features like goto declaration/definition or autocompletion - you don't get info about types of the symbols, their visibility etc. - this is all hidden in the implementation of the LSP server.
Further, you are not even guaranteed that the server implements the textDocument/documentSymbol call in which case you won't implement anything on top of that - yet the server may provide the goto declaration/definition call or autocompletion functionality.
You already implement complex features like symbol tree and call tips and more using LSP so the protocol itself must be sufficiently suitable for us, right?
Symbol tree isn't a complex feature in terms of symbol processing - you just display them (it's just all the annoyance with GtkTreeView). But if you want to implement a good autocompletion or symbol goto taking into account the symbol visibility, you just have to call the corresponding LSP call - without this you'd degrade the whole LSP to the not-so-good TM-style goto or autocompletion and the LSP doesn't make sense here.
And again, the protocol itself is sufficiently suitable - you just have to call the corresponding LSP method for each of the features at the right place which this PR is all about.
To be clear, I don't insist the implementation has to look exactly the way I propose here. In the worst case, if this is considered too intrusive, I could probably live with some API that just disables the corresponding Geany features - Matthew did something like that in #592. I was just hoping for more native experience - for instance that you can use the same keybindings for symbol goto, tooltips, or autocompletion like the one Geany uses so the plugin doesn't need an extra set of its own keybindings. But I'd probably survive that.
Another thing is the symbol tree which is probably the only feature which works in a more or less same way in LSP as in TM and doesn't bring much benefit compared to TM. So this one could be completely dropped if the patch is considered too big.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.