| 
Hi Mikael,   I created an issue to ask for clarification:
https://github.com/Microsoft/language-server-protocol/issues/475   Thanks, Markus   
From: <lsp4e-dev-bounces@xxxxxxxxxxx> on behalf of Mickael Istria <mistria@xxxxxxxxxx>Reply-To: lsp4e developer discussions <lsp4e-dev@xxxxxxxxxxx>
 Date: Friday, 4. May 2018 at 09:46
 To: lsp4e developer discussions <lsp4e-dev@xxxxxxxxxxx>
 Subject: Re: [lsp4e-dev] Requesting feedback to a change that adds support for nested sub-projects to LSP4E
 
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. |