@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 or view it on GitHub:
https://github.com/geany/geany/pull/3571#issuecomment-1793578723
You are receiving this because you are subscribed to this thread.

Message ID: <geany/geany/pull/3571/c1793578...@github.com>

Reply via email to