You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Other people might have different options. On a normal week I create dozens of throwaway Scala scripts and worksheet sessions, where I'd want to have consistent formatting (well, consistent according to my tastes, of course, everyone is different).
FR: I would like the ability to customise the scalafmt config that Metals creates
Describe the solution you'd like
I propose having a configuration setting that Metals accepts, which creates a named list of Scalafmt config options:
The names of configs are user-defined, they don't indicate any connection to the Scala version
If config is specified, options field is requied
version field is optional, and defaults to current latest that Metals can identify
defaultForScala3 and defaultForScala2 fields are optional and only 1 config can be marked so
In the absence of this config or if the scalafmtTemplates is empty, default to current Metals behaviour
If the config is non-empty, offer user a choice of which file to create
If there's only 1 Scala version in the project, and there exists a config with defaultForScala* property set to true, create .scalafmt.conf without asking the user, then run the formatting request
If the template contains version field, it's preserved
If the template doesn't contain version field, it gets added with latest Scalafmt version Metals knows about
Describe alternatives you've considered
Manual management of Scalafmt configs, but this is quite cumbersome.
I believe silently creating scalafmt config if the user explicitly configured their Metals is a good UX.
Additional context
No response
Search terms
scalafmt, metals, config
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently Metals suggests creating Scalafmt config on first issue of the formatting request.
By default, it adds a very unopinionated config (e.g. here for Scala 3 project):
While convenient, this is quite limited.
For example, in pretty much all of my project I use the same Scalafmt config starter:
Other people might have different options. On a normal week I create dozens of throwaway Scala scripts and worksheet sessions, where I'd want to have consistent formatting (well, consistent according to my tastes, of course, everyone is different).
FR: I would like the ability to customise the scalafmt config that Metals creates
Describe the solution you'd like
I propose having a configuration setting that Metals accepts, which creates a named list of Scalafmt config options:
options
field is requiedversion
field is optional, and defaults to current latest that Metals can identifydefaultForScala3
anddefaultForScala2
fields are optional and only 1 config can be marked soscalafmtTemplates
is empty, default to current Metals behaviourdefaultForScala*
property set to true, create.scalafmt.conf
without asking the user, then run the formatting requestversion
field, it's preservedversion
field, it gets added with latest Scalafmt version Metals knows aboutDescribe alternatives you've considered
Manual management of Scalafmt configs, but this is quite cumbersome.
I believe silently creating scalafmt config if the user explicitly configured their Metals is a good UX.
Additional context
No response
Search terms
scalafmt, metals, config
The text was updated successfully, but these errors were encountered: