Support user choice of LSPs in vscode

[robmwalsh]

Is your feature request related to a problem? Please describe.

Continued from scala/vscode-scala-syntax#179 (comment)

There's currently no way in vscode to work around conflicting extensions. With both @fommil and I now working on LSPs for scala, it'd be great if there was a way for vs code users to choose which option they want to use without having to disable conflicting extensions. I think something like how you can change BSP between Bloop and SBT would be good.

Describe the solution you'd like

Practically, this could be done via is a minimal vscode extension that does nothing except allow users to choose their LSP (via a command palette option), potentially per workspace. Each project's vscode extension could then depend on this minimal plugin, and would only launch the corresponding LSP server if the minimal extension indicates that it should, and should similarly shut down if the user changes their LSP preference.

I'm happy to do the legwork on this, but I'm also open to other suggestions if anybody has any better ideas.

Describe alternatives you've considered

I've looked into docs for ways to manage other extensions and it seems the answer is pretty much "you can't", the only real options are manually disabling conflicting plugins or having a cooperative approach like I've suggested above.

It would be possible to do something silly like have the minimal extension monitor for LSPs and shut down the processes of the LSPs that aren't currently selected by the user but that's hacky and probably more work than I've suggested.

Additional context

No response

Search terms

Lsp alternatives user preferences

[tgodzik]

Thanks for reporting! I am not sure if it's something we would want to pursue, it adds complication, while it should essentially be just a case of disabling/enabling two extensions. If there are issues with that we can try and work on it, but it might bring more complication to the extension to have Ensime included. Especially, that we have a lot of custom stuff that would not work with Ensime.

I am also not sure of how would it work exactly. Ensime is not published anywhere and it only allows you to build it yourself, so if a user switches to Ensime it will almost 100% not work out of the box. We can't also create issues in case of problems, since there is no issue tracker on purpose. Potentially users will start reporting issues in the metals-vscode repository, which would be a bit weird.

I think the easiest solution here would be to make disabling/enabling extensions seamless.

[robmwalsh]

No changes to metals would need to be made, only the vscode-metals extension.

You raise a good point about users without ensime trying to switch to it. A solution here would be to have the various vscode extensions register themselves with the minimal extension so that only installed options show up. If there's only one LSP installed, the command palette option to change LSP could be hidden entirely.

Users that haven't got ensime installed then wouldn't have the option to switch.

If I can make it so the experience for users with only metals installed is literally unchanged, would you consider a PR to make the required changes to vscode-metals?

RE making enabling/disabling extensions seamless, there's been ongoing discussions in the vs-code repo since around 2018 with no real progress. Somebody made a script that parses and patches a "not for editing" config file, but that's a recipe for disaster.

[Arthurm1]

@robmwalsh Have you tried using https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_69.md#settings-profiles

It's enabled under workbench.experimental.settingsProfiles.enabled but looks like it does what you want.

It would also allow including/excluding the scala syntax extension if one of the LSPs doesn't need it, or allow you to include other LSPs like the Java one if your Scala LSP worked alongside that.

[robmwalsh]

@Arthurm1 thanks - that does look like it'll do the trick. Looks like it's still considered experimental but I'll close this issue anyway - the comments indicate that its a highly requested feature so its unlikely to get canned at this point. Thanks all for your thoughts on this :)

[fommil]

Ensime is not published anywhere

ENSIME is published at https://ensime.github.io/

[tgodzik]

Ensime is not published anywhere

ENSIME is published at https://ensime.github.io/

I just meant the it's not published as a jar anywhere. And I didn't mean to be negative here, it's just the current approach is widely different to Metals and it would be much harder to integrate them together instead of just switching extensions.

If you feel like including both in a single extension is sensible, I would be open to that, but I don't want to make any promises that I will work on it.

[robmwalsh]

This was never a suggestion to integrate them together, it was literally just making it easier to switch between them - each wouldn't need to know about the other with what I suggested, they'd just need to know if the user wants to use it at the moment. I quite like the idea of being able to use ensime on my laptop when power is a concern and at home metals or my lsp depending on what I'm trying to do.

In any case, @Arthurm1 's suggestion seems to address this, which is why I closed the issue.