Replies: 3 comments 2 replies
-
Sounds good! |
Beta Was this translation helpful? Give feedback.
0 replies
-
👍🏼 I think this would be good to get rid of the extra step. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Hey @adpi2 just letting you know I started on this. I have working pretty much what you explained.
Notice there is no |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
When the user wants to connect Metals to sbt server it can use two commands which are slightly different:
BspSwitch
: This command only works if the.bsp/sbt.json
file is already available. The user can then selectsbt
and Metals will connect to it. If the.bsp/sbt.json
is absent, Metals will not propose to connect to sbt, which is source of confusion or disapointment.GenerateBspConfig
: This command forces the generation of a.bsp/sbt.json
file by runningsbt bspConfig
. Then Metals read the generated.bsp/sbt.json
file to connect to sbt server. This method is slower than the first one because sbt is loaded twice.This situation is not ideal because:
.bsp/sbt.json
file then read and run theargv
command`).Ideally the user should not need to understand that complexity and it should be able to use the same command in every situation.
I propose to make
BspSwitch
the default command to connect to sbt server:If there is no
.bsp/sbt.json
file, Metals will check the version of sbt (it must be bigger than 1.4.1) and if it is it will suggest to connect to sbt. After the user choosessbt
and because.bsp/sbt.json
is absent, it will runsbt bspConfig
and connect to sbt server.GenerateBspConfig
will still be useful to force the generation of a new BSP config, but it would rarely be used.Beta Was this translation helpful? Give feedback.
All reactions