sbt --clientworks but still has bugs with autocompletion and disconnects on Mac so
sbt --clientfirst in the workspace, then open the project in Metals if you've chose sbt as a BSP server
.bsp/<server>.jsonfile exists, that's an indication that it should be started. So in this situation when you've chosen to use sbt as a build server at some point in time and open the project, metals remembers that, follows BSP discovery rules and starts the server since it needs that in order to function
There's this setting already:
Optional absolute path to an sbt executable to use for running sbt bloopInstall.
By default, Metals uses java -jar sbt-launch.jar with an embedded launcher while respecting .jvmopts and .sbtopts.
Update this setting if your sbt script requires more customizations like using environment variables.
But this is not honored.
It should at least be a flag one can set in the preferences that make Metals wait for a server instead of starting one.
But metals would sort of be unusable until that happened
So does starting sbt server first and then vs code work in this scenario?
Yes, it would, but I want to of course use the integrated terminal to avoid alt-tabbing between the windows. Most people prefer that I think.
testwhen I want
Because SBTN is a buggy mess.
there has been a ton of work on the sbt side on sbtn, so please refrain from shitting on it here