Re: [lsp4e-dev] Requesting feedback to a change that adds support for ne

[Mickael Istria <mistria@xxxxxxxxxx>]

On Mon, May 14, 2018 at 10:54 AM, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx> wrote:

Sorry, I must have misunderstood the discussion then. I thought there are concerns changing the current behavior because of existing implementations.

We currently didn't investigate enough existing implementations to evaluate whether there are actual concerns or not.  So whether we do need to handle both cases or not is still not set; and if it happens that all LS that were tried do work with the proposal, we'll just change the behavior to the proposed one without leaving more choices, as choice is a development and maintenance effort that should only be paid if there is value from it.

 

But there is also a requirement to support a different behavior for a specific LS.

Isn't that a use-case already?

ATM, this requirement is not yet qualified and we don't have any use-case for it. Maybe upcoming tests on aCute and Corrosion would say the contrary.

 

Maybe the LSP should provide a `workspace/canHandleFile` request ?  

I'm not sure why the protocol needs an extension. The concept of projects and sub-projects is pretty specific to Eclipse.

I don't think it's specific to Eclipse IDE. I believe the doubts here come from the fact that the LSP doesn't define what's a "workspaceRoot" nor defines which subpart of the tree is a LS expected to cover. Naturally, it would seem that it would cover the whole subtree, with submodules.

But let's imagine the following case: 1 Maven project with 2 sub-folders, only one of them being a module, and the other one being an unrelated Gradle project; what is the expectation of how to load LS here? I don't think there is a common rule for all projects and languages here, and this is probably specific to each LS, hence why I believe that this should be up to LS to say whether it can process a given file or not more than to IDEs or integrators to hardcode such decision in an arbitrary way.

 

Instead, the bridge between the LS and Eclipse needs to provide the correct adaption between Eclipse and the LS.

This has a cost in development and maintenance. Unless I'm proven there is value (with concrete examples) and someone is willing to implement a strategy for integrator to switch between one or the other; I'd rather keep LSP4E consistent and using a common rule here.

As mentioned, I'll try aCute and Corrosion later this week and will report whether the proposal breaks them or not. Please try your LS too.