Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [lsp4e-dev] [CAUTION] Re: Requesting feedback to a change that adds support for nested sub-projects to LSP4E

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

 


--
Christoph

 

From: lsp4e-dev-bounces@xxxxxxxxxxx [mailto:lsp4e-dev-bounces@xxxxxxxxxxx] On Behalf Of Ofterdinger, Markus
Sent: Montag, 7. Mai 2018 09:57
To: lsp4e developer discussions <lsp4e-dev@xxxxxxxxxxx>
Subject: [CAUTION] Re: [lsp4e-dev] Requesting feedback to a change that adds support for nested sub-projects to LSP4E

 

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

 

Hi,

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.

Cheers,


Back to the top