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
Uh oh!
There was an error while loading. Please reload this page.
-
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.jsonfile is already available. The user can then selectsbtand Metals will connect to it. If the.bsp/sbt.jsonis 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.jsonfile by runningsbt bspConfig. Then Metals read the generated.bsp/sbt.jsonfile 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.jsonfile then read and run theargvcommand`).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
BspSwitchthe default command to connect to sbt server:If there is no
.bsp/sbt.jsonfile, 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 choosessbtand because.bsp/sbt.jsonis absent, it will runsbt bspConfigand connect to sbt server.GenerateBspConfigwill 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