| Would it make sense to make a default but allow LS implementors providing their own policy?
Looking at the review, it could keep the complexity out of LanguageServerWrapper and allow to provide custom/pluggable extensions to allow flexibility for the project to LS mapping.
-Gunnar
Hi all, Dbaeumers response does not sound like the protocol will change in this respect: “Actually the specification intentionally doesn't clarify this since it might depend on the server implementation. For example the TSServer handles all workspace root folders and nested projects in one server. The MS C++ server can only handle on project pre server and the client starts a server per project and dispatches the requests to the corresponding server. For VS Code we even maintain two example projects demos both use cases here: https://github.com/Microsoft/vscode-extension-samples” Hi Mikael, Thanks, Markus Thanks a lot for this interesting proposal and opening it for discussion. As mentioned on the bug, I think you should immediately consider enabling multi-root support in your LS to workaround this issue (additionally to the tremendous perf benefit brought by 1 LS per workspace instead of 1 LS per project). That said... I think it's also worth starting the discussion on the LSP tracker itself about whether the protocol should emit some documentation, constraints or recommendations for such case: is a language-server expected to serve for all children file of the root folder? Can you please bring this to the LSP spec too? LSP4E can take a pragmatic choice independently of the spec: if we see all LS that are used over LSP4E these days do work for any child under a project, let's not make the spec a blocker and let's proceed with your proposal.
I'll have to check with Eclipse aCute (Omnisharp-Roslyn language server) and Eclipse Corrosion (RustLS) but I'm quite busy today and I'm on PTO for a week after that. Lucas is also on PTO for 2 or 3 weeks IIRC, so we won't be able to provide feedback about those projects before ~10 days.
If after extensive thoughts and testing (ideally against aCute and Corrosion too) some other committers are fine merging this change in my absence, I'm all fine with it. I don't want to be a blocker here.
|
