@kugel- I'm really getting tired of these endless discussions that don't lead anywhere. On the one hand you say "I like LSP because it seems to be industry standard by now with lots of server-implementations", on the other hand you say "Maybe if LSP severely limits the features we may implement it's not the right tool for us". You should make your mind what you want. You are inventing some artificial reasons why it shouldn't work but the reality is that lots of editors use it and it works. My plugin works as well, try it. Period.

Let me put it very clearly: I am only interested in implementing a LSP plugin in a way that the LSP interface is supposed to be used. I'm not interested in any Frankenstein LSP implementation where we for some unknown reasons ignore the features LSP offers and implement it in a worse way because the only blessed interface is textDocument/documentSymbol which doesn't provide all we need. Please notice the I in the sentence - this doesn't mean that someone else cannot try to do something else, I just don't want to waste my time on that. Feel free to e.g. fork the plugin I'm developing and doing what you want.

@b4n @eht16 @elextr What's your opinion on this? This really affects whether I should keep developing the plugin. Using LSP only as an alternative source of tags doesn't make sense to me because it won't bring any better autocompletion or symbol goto so why bother. The interface as proposed in this PR doesn't have to stay this way and the scope can be reduced, but as the minimum I need to be able to disable some Geany's features to avoid e.g. two autocomplete popups, one from TM, one from LSP.

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