Make Metals more Robust

[odersky]

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

After having experienced another batch of 400 students starting their Scala journey with Metals here are some of the painpoints which would be great to fix. It' s second hand, if needed I could rope in some of the TAs who supervised the students. /cc @mbovel @adpi2 @bishabosha

Describe the solution you'd like

Some suggestions:

1. Make project detection more robust. Students do not always start their project in the perfect directory, but if they don't nothing is recognized. Is there no way for a more general search in the environment to find scala and project files?
2. Coming from IntelliJ some students were surprised that auto-save was not on and they had to do ^S manually. I actually think this is not so much of a problem. But maybe one could show a helpful popup box if a student did not save for the first N minutes? The box should contain a tick box "don't show this again".
3. The last one is more my own observation: We need to make the compiler connection more resilient. I noticed that sometimes Metals gets lost and shows a pop up box stating that the build server did not respond for a minute and one should consider a restart. That box should contain the restart button! Instead it just gives "OK" and "Dismiss", neither of which seems to do anything.
4. Generally, a restart button or menu item somewhere would be a great addition. This should flush all the dot files and caches and restart the build server. It's a total putdown that one still has to do that sometimes manually.

Describe alternatives you've considered

We considered using IntelliJ instead, since that's what students are used to from first year.

Additional context

No response

Search terms

Robustness, resilience

[odersky]

If the issue in 3/4 is that it's sometimes hard to cancel a compiler run we should work together to make this possible. We could make the presentation and build compilers watch InterrupedExceptions, for instance, or watch some other cancellation signal.

[adpi2]

3. The last one is more my own observation: We need to make the compiler connection more resilient. I noticed that sometimes Metals gets lost and shows a pop up box stating that the build server did not respond for a minute and one should consider a restart. That box should contain the restart button! Instead it just gives "OK" and "Dismiss", neither of which seems to do anything.

I have the same experience and I think we both use sbt as the build server. I often receive the pop up even if sbt is still running and responding.

[tgodzik]

Thanks for reporting and the great feedback! This is something we are trying to get right.

I have the same experience and I think we both use sbt as the build server. I often receive the pop up even if sbt is still running and responding.

This is a new feature and seems not work 100% yet. We want to move it to the status bar, which should be visible and not that intrusive at the same time scalameta/metals#5660 There have also been some fixes around that

Make project detection more robust. Students do not always start their project in the perfect directory, but if they don't nothing is recognized. Is there no way for a more general search in the environment to find scala and project files?

We are trying some approaches:

• we currently default to Scala CLI if no project is detected (any build tool)
• automatically search for project root at least a couple of levels down(should be available in the next release)

Coming from IntelliJ some students were surprised that auto-save was not on and they had to do ^S manually. I actually think this is not so much of a problem. But maybe one could show a helpful popup box if a student did not save for the first N minutes? The box should contain a tick box "don't show this again".

That might be hard to do 100 % and not show wrong warnings, we have the same problem with the flaky status. It seemed obvious at first, but now we need to make it more reliable. But it's worth thinking about it. I wonder if VS Code could change the default here.

The last one is more my own observation: We need to make the compiler connection more resilient. I noticed that sometimes Metals gets lost and shows a pop up box stating that the build server did not respond for a minute and one should consider a restart. That box should contain the restart button! Instead it just gives "OK" and "Dismiss", neither of which seems to do anything.

That's the biggest issue we have currently, that's where our recent improvements are trying to improve things. Switching to named sockets could also help, but the problem is that there are multiple issue that can contribute here:

• connection flakiness
• zinc issues
• Bloop/sbt issues
• compiler issues, which are more prominent if the code is heavily edited

But we are looking into it!

Generally, a restart button or menu item somewhere would be a great addition. This should flush all the dot files and caches and restart the build server. It's a total putdown that one still has to do that sometimes manually.

There is a "clean and restart build server" command both within the command palette as well as in the metals view. The only improvement I can think of is trying to figure out how we can show it as an actual button, but vs code tree view is not easy to make it work.

[mbovel]

Make project detection more robust. Students do not always start their project in the perfect directory, but if they don't nothing is recognized. Is there no way for a more general search in the environment to find scala and project files?
We are trying some approaches:

• we currently default to Scala CLI if no project is detected (any build tool)
• automatically search for project root at least a couple of levels down(should be available in the next release)

Super excited to read there is work on this! How does the automatic search for project root work? What happens if it finds several projects?

For our use-case, I believe the following would be super useful: “if a Scala file is opened, and one of its parent directories has a build.sbt, but this directory is not the project root, then show a warning”.

Coming from IntelliJ some students were surprised that auto-save was not on and they had to do ^S manually. I actually think this is not so much of a problem. But maybe one could show a helpful popup box if a student did not save for the first N minutes? The box should contain a tick box "don't show this again".

I don't think Metals should be concerned by that. We could and did in the past set files.autoSave to afterDelay in the project's VSCode settings, but this has other drawbacks, like re-triggering compilation or showing errors while editing unfinished code. That might be old-school, but I'd rather teach students ctrl-S 😉

[tgodzik]

Super excited to read there is work on this! How does the automatic search for project root work? What happens if it finds several projects?

I will open the first one found currently, mostly to handle cases where project definition is not at the root. We don't handle multiple projects. We could potentially treat them the same as we do with multiple workspace folder. But no one currently reported a case like that.

For our use-case, I believe the following would be super useful: “if a Scala file is opened, and one of its parent directories has a build.sbt, but this directory is not the project root, then show a warning”.

That could be a nice improvement and we could show a command to reopen with the correct folder (at least in vs code, this would vary per editor).

[bishabosha]

If the issue in 3/4 is that it's sometimes hard to cancel a compiler run we should work together to make this possible. We could make the presentation and build compilers watch InterrupedExceptions, for instance, or watch some other cancellation signal.

addressing scala/scala3#13082 should fix this which at least has a cooperative cancellation with bsp