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".

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.

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 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? You use DocumentSymbol in your reference plugin as well, after all.

[1]: The asynchronous architecture is an obstacle, that's right, but to me that's just necessary refactoring. GIO would allow us to use TM in an async fashion as well. Just need to teach code that tags are not immediately available after document_open_file_full() but rather after some "document-tags-ready" signal. That would probably also allow us to improve start-up and project-loading scenarios.

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