Multiple languages specific editor settings

[aartoni]

We definitely need the ability to set those for multiple languages at once.

Something like:

// Once for all
"[cpp, c]":{
    "editor.formatOnSave": true
}

Instead of:

// Once for C++
"[cpp]":{
    "editor.formatOnSave": true
},

// And once for C
"[c]":{
    "editor.formatOnSave": true
}

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Workspace does not respect editor.formatOnSave config from folder settings (#49708)
• Group some common settings for languages (#41209)
• Feature request: customized settings for specific files and folders (#50888)

[ZigZagT]

really want it! we are using something like [json,jsonc,yaml] which is really hard to maintain

[ghost]

I would like this as well but should the logic around having a duplicate setting for the same language? Should there be a hierarchy, ie having the settings pull from the single language specification over the multiple language specifications?

E.g. get settings for javascriptreact from [javascriptreact] over [javascript, javascriptreact]?

"[javascript, javascriptreact]": {
    "editor.insertSpaces": true
},
"[javascriptreact]": {
    "editor.insertSpaces": true
}

[simonhaenisch]

Yup, also want this. Currently it's just a bit of a pain.

{
  "[yaml]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
  },
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
  },
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
  },
}

[JosephTLyons]

Would love this feature, tons of duplicated settings in my settings file and this feature would clean it up quite nicely and reduce copy/pasta accidents.

[jwmann]

Also adding my +1 for this 👍

[liamross]

Looks like it's "On Deck" for consideration for an upcoming release so that's good news!

[balupton]

Please just emoji 👍 the original post at the top, that way your demand is expressed without notifying everyone who is subscribed for updates

[hyoretsu]

Would be nice for a simple rule to not be this long

 "[javascript]": {
  "editor.codeActionsOnSave": {
   "source.fixAll.eslint": true
  }
 },
 "[javascriptreact]": {
  "editor.codeActionsOnSave": {
   "source.fixAll.eslint": true
  }
 },
 "[typescript]": {
  "editor.codeActionsOnSave": {
   "source.fixAll.eslint": true
  }
 },
 "[typescriptreact]": {
  "editor.codeActionsOnSave": {
   "source.fixAll.eslint": true
  }
 },

[gitpancake]

Gotta add my +1 for this! 🎉

[marcusrbrown]

I would like this as well but should the logic around having a duplicate setting for the same language? Should there be a hierarchy, ie having the settings pull from the single language specification over the multiple language specifications?

E.g. get settings for javascriptreact from [javascriptreact] over [javascript, javascriptreact]?

"[javascript, javascriptreact]": {
    "editor.insertSpaces": true
},
"[javascriptreact]": {
    "editor.insertSpaces": true
}

Should the second entry in this example be treated as a duplicate object key?

[gitpancake]

@igetgames

Rather than duplicate object key, perhaps if there are duplicate settings for the same language then a warning message could appear.

In the code example above:

"[javascript, javascriptreact]": {
    "editor.insertSpaces": true
},
"[javascriptreact]": {
    "editor.insertSpaces": true
}

A warning message could appear along the lines of:

The setting editor.insertSpaces is configured multiple times, in: [javascript, javascriptreact] and [javascriptreact]

[Naxos84]

But only if it has an identical value.

"[javascript, javascriptreact, typescript, typescriptreact]": {
    "editor.insertSpaces": true,
    "editor.formatOnSave": true
},
"[javascriptreact]": {
    "editor.insertSpaces": false
}

in this example I'd expect it to have a different behaviour ONLY for "javascriptreact".
So no warning in this case.

[gitpancake]

That could overwhelm a user and add un-needed complexity. A warning should appear on the key, irrespective of the value. I think that would be a nicer user experience overall.

[v-kydela]

@RMacfarlane
@alexdima
@sandy081

Any updates?

[hyoretsu]

@Szymono you do realize VSCode's the open-source one right?... You can view the source code, it's under MIT license and anyone can fork/make a PR for it.

[brunobmello25]

@Szymono well you could fork it and implement this feature instead of calling developers stupid just because they couldn't attend to it yet. That's because, you know, it is open source

[gitpancake]

Hey let's keep this thread peaceful and productive please. I would love to see this implemented at some point.

[CEbbinghaus]

I had a Glance at the repo and while I do not have the time to work on this at the moment I think this is a good place to start when looking to implement such a feature:

https://github.com/microsoft/vscode/tree/main/src/vs/workbench/services/preferences/common/preferencesModels.ts

[anderium]

I tried to search a bit deeper into where this could be implemented so I'll leave what I found here.

A test for language specific settings in configurationModels.test.ts shows us that the configurationModelParser is the object that parses settings. If I understand correctly this creates an object _raw representing the JSON settings which is parsed into a settings tree of the form {"editor": {"formatOnSave": false, …}, …}. (I'm kind of unsure about this, but it seems what's being tested.)

Settings are being tested for satisfying OVERRIDE_PROPERTY_PATTERN, the Regex pattern \[.*\]. This allows the usage of all characters, whereas the currently expected behaviour would probably be to only accept lowercase. (I don't remember what I'm basing this on, but if I recall correctly the languages are defined only with lowercase characters.)

Right below this Regex pattern there's the function overrideIdentifierFromKey which returns the language associated for the settings to override. It does this by assuming the input is structured as [language]. Even spaces are not removed from the language identifier, but adding spaces is not a problem because these do get stripped later. Either way, this function is referenced nine times in the whole code base over 5 files. See these results. Most of these references do not strip away any excess spaces, however, two do: toOverrides and DefaultConfigurationModel. I'm thinking all of the cases referencing the function will have to be updated to accommodate specifying multiple languages, but perhaps a start can be made at the functions specifically trimming extra whitespace.

I've also thought lightly on how best to store these settings. I think storing them for each language individually is okay. This is what we're doing without this feature anyway, and other methods would likely require more complicated requests for settings than how it works now. Those would likely not only slow down when multiple languages are defined, but always make loading the settings slower.

Here I copy some of the behaviour we want from above so it's easier to find:

Doubly configured with same value:

"[javascript, javascriptreact]": {
    "editor.insertSpaces": true
},
"[javascriptreact]": {
    "editor.insertSpaces": true
}

Could be accepted or give a warning message along the lines of:

The setting editor.insertSpaces is configured multiple times, in: [javascript, javascriptreact] and [javascriptreact]

Doubly configured with different value:

"[javascript, javascriptreact, typescript, typescriptreact]": {
    "editor.insertSpaces": true,
    "editor.formatOnSave": true
},
"[javascriptreact]": {
    "editor.insertSpaces": false
}

Should be accepted and use "editor.insertSpaces": false for javascriptreact.

Doubly configured in disjoint sets (different value):

{
    "[javascript, typescript]": {
        "editor.insertSpaces": true
    },
    "[javascript, plaintext]": {
        "editor.insertSpaces": false
    }
}

Should be accepted and use "editor.insertSpaces": false for javascript. The last case should be the one that gets used.

Doubly configured in disjoint sets (same value):

{
    "[javascript, typescript]": {
        "editor.insertSpaces": true
    },
    "[javascript, plaintext]": {
        "editor.insertSpaces": true
    }
}

Should be accepted and use "editor.insertSpaces": true for all three languages. The warning suggested for multiple configurations should probably not be issued because the setting wasn't defined for plaintext before. This might mean it's difficult to determine when to give such a warning or we can accept that the warning is given, letting users choose to ignore it. Since we'll take the last override, it won't matter to us in the end.

[CEbbinghaus]

Did it

[sandy081]

Implemented this feature and you can configure editor settings for multiple languages with single key as follows:

"[cpp][c]":{
    "editor.formatOnSave": true
}

We already use this syntax in the setting workbench.colorCustomizations eg.,

"workbench.colorCustomizations": {
		"[GitHub Sharp][GitHub Sharp Dark]": {
                       "editorPane.background": "#d6d0d01a",
			"sideBarSectionHeader.border": "#D3D3D3",
                 }
}

Hence, went with this syntax also here to define multiple languages.

[CEbbinghaus]

@sandy081 How come you decided to separate the languages into separate brackets?

"[cpp][c]":{
"editor.formatOnSave": true
}

The original issue called for it to be a comma-separated list inside the brackets and it's a lot more semantic with less verbosity. If you want to overload 20 languages that you have to match up 20 brackets for and if one of them is malformed it's likely an invalid key. A single bracket is plenty sufficient and reduces the clutter from the additional characters:

"[javascript][typescript][json][html][jsx-tags][yaml][editorconfig][dotenv][astro][javascriptreact]":
{
    "editor.formatOnSave": true
}

"[javascript, typescript, json, html, jsx-tags, yaml, editorconfig, dotenv, astro, javascriptreact]":
{
    "editor.formatOnSave": true
}

[janosh]

While we're at it, why not be as forgiving as possible and allow no brackets at all

"javascript, typescript, json, html, jsx-tags, yaml, editorconfig, dotenv, astro, javascriptreact":

as well as no spaces

"javascript,typescript,json,html,jsx-tags,yaml,editorconfig,dotenv,astro,javascriptreact":

[sandy081]

@CEbbinghaus It was decided by the team - we already use the same syntax in workbench.colorCustomizations setting and this makes it consistent.

[MoKhajavi75]

Hey

When can we use it?

It's not supported in:

Version: 1.62.3
Commit: ccbaa2d27e38e5afa3e5c21c1c7bef4657064247
Date: 2021-11-17T08:00:36.721Z
Electron: 13.5.2
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 5.4.0-90-generic

cc @sandy081

[sandy081]

With next release - 1.63.0. You can also try insiders channel to use it now - http://code.visualstudio.com/insiders/