Hi Gunnar,
To make this behaviour configurable is also fine with me. But even if it’s configurable you have to add some complexity to the LanguageServerWrapper, since it has to evaluate the configuration and adapt the behaviour
during runtime. I’m not so deep into the LSP4E plugin, but from my understanding the LanguageServerWrapper decides if a new instance of a language server is created or not. The language server itself can’t prevent the creation of a new instance for a nested
sub-project, this decision is done by the wrapper. Please correct me if I’m wrong.
What would be the right approach to make this configurable? Enhance the LSP extension point?
Thanks,
Markus
From:
<lsp4e-dev-bounces@xxxxxxxxxxx> on behalf of Gunnar Wagenknecht
<gunnar@xxxxxxxxxxxxxxx>
Reply-To: lsp4e developer discussions <lsp4e-dev@xxxxxxxxxxx>
Date: Tuesday, 8. May 2018 at 20:04
To: lsp4e developer discussions <lsp4e-dev@xxxxxxxxxxx>
Subject: Re: [lsp4e-dev] [CAUTION] Re: Requesting feedback to a change that adds support for nested sub-projects to LSP4E
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
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”
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.
_______________________________________________
lsp4e-dev mailing list
lsp4e-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/lsp4e-dev
|
