scalameta / metals-feature-requests

Issue tracker for Metals feature requests
37 stars 4 forks source link

Support to ms live share in vs code #356

Open larochef opened 1 year ago

larochef commented 1 year ago

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

When using the live share extension on scala projects, merals tries to start it fails with the following error: FileSystemNotFoundException: Provider "vsls" not installed

Could there be a way to reuse the host metals or have it to work with the remote fs?

Describe the solution you'd like

I'd like metals to be able to start and have all common features working when connected on someone else computer

Describe alternatives you've considered

-

Additional context

No response

Search terms

live share

tgodzik commented 1 year ago

Thanks for reporting! I wonder why does VS Code expect the plugin authors to understand vsls provider :thinking: Would we need implement FileSystemProvider for it?

We would need to figure out a low cost way of doing it, though I worry that the current Metals model doesn't work well here.

tgodzik commented 1 year ago

Actually, we might need to do this https://github.com/redhat-developer/vscode-java/pull/492

tgodzik commented 1 year ago

Actually, we do have that :thinking:

tgodzik commented 1 year ago

I did some digging and it seems your error shows up if the guest has the Metals extension enabled for the liveshared workspace. Since there is currently no way to make it work via remotely installed extension as there is no way for Metals to access that file system. If anyone knows how to do it we could try it out. I assume it would be possible if Metals asked the client about the filesystem with a custom extension to the LSP. This would be similar to an approach we took in the breadcrumbs PR (though currently unmerged sadly as it turned out to be a more complex rewrite)

To make it work currently you should do it the other way around. The host should have Metals enabled and the guest disabled for that liveshared workspace. I think no extensions are actually turned on if they don't declare that capability. In this situation, host extension will do the work here forwarding everything to the guest. Though I see some things like virtual documents do not work in that case, which might require some improvements.

larochef commented 1 year ago

NIce, thank you for this time. I understand and I will try disabling metals next time and see what happens.

Do you think it would be possible to have metal not starting in this situation? It would still be a first step better than having to disable metals manually

tgodzik commented 1 year ago

NIce, thank you for this time. I understand and I will try disabling metals next time and see what happens.

Do you think it would be possible to have metal not starting in this situation? It would still be a first step better than having to disable metals manually

I think that's the default behaviour, we had to add them manually for the guest to reproduce the error. Maybe you added it manually at some point and now it turns on by default?

larochef commented 1 year ago

As far as I remember, I didn't configure anything on metals and didn't do anything in particular, it was a fresh metals install on my side.

tgodzik commented 1 year ago

Hmm... seems like we need to look into it at some point, there doesn't seem to be any clear information what an extension should do to support live share properly (as far as I am aware of)

Current workaround is to disable metals for a workspace you are the guest in.