[themes] Allow custom variables and references in workbench color customizations section

[yuval-gilboa]

This is a feature request to allow defining custom color variables in the workbench color customizations section. It would allow creating a small palette of colors and reusing it across the workbench color definitions, saving many repetitions and making it much easier to maintain.

This is just simple text substitution based on some naming convention like the .less @variable convention. For example, see the @PaletteXXX variables in the sample below:

"workbench.colorCustomizations": {

      // custom colors
      "@Palette000": "#FFFFFF",
      "@Palette050": "#ECEFF1",
      "@Palette100": "#CFD8DC",
      "@Palette200": "#B0BEC5",
      "@Palette300": "#90A4AE",
      "@Palette700": "#455A64",

      // input control
      "input.background": "@Palette000",
      "input.foreground": "@Palette700",
      "input.placeholderForeground": "@Palette200",
      "inputOption.activeBorder": "@Palette300",
      "input.border": "@Palette100",

      // list views
      "list.activeSelectionBackground": "@Palette200",
      "list.activeSelectionForeground": "@Palette700",
      "list.inactiveSelectionBackground": "@Palette100",
      "list.hoverBackground": "@Palette100",
      "list.dropBackground": "@Palette100",
      "list.focusBackground": "@Palette100",

[aeschli]

Interesting idea!

[angelhdzdev]

Was this implemented or not yet? I also need to define custom variables in workspaces not to repeat myself.

[kanlukasz]

It should be implemented.

Why:

• When creating themes (and / or scope colors) with many colors, it is difficult to manage them

An example of how the theme is created in Sublime Text:

[runxel]

I'm really astonished how this could be forgotten. VS Code is great so far, but this is a real big oversight, imho.
Also not supporting HSL(A) is a pain. :D

[videopilot]

This is something that Atom does really well. It allows creating variables as well as having other variables based on modifications to those. So for example, and overall blue theme could really just specify one blue color and lighter and darker elements would be based on that.

[muuvmuuv]

Would even take it further and say that this should also be modifiable by user settings. So for example I use the ayu-light theme and I don't like the orange highlighting, in my settings I would then override theme variables and tokens that are defined by the author:

{
  "workbench.colorCustomizations": {
    "teabyii.ayu": {
      "@primary": "hsl(40, 40%, 20%)"
      "input.background": "#2cbe4f", // previously `@primary`
    }
  },
}

This would allow modifying themes differently, since VS Code now has a dark and night theme switch.

[memeplex]

#73069 was closed as dup of this although I believe the intention was different: to refer to colors already defined by themes, not to variables defined by the end user. For example, if I want the base foreground color for markdown emphasis, instead of the more colorful variants many themes apply, I would like to express "for this use what this theme defines as the default foreground color" without having to hardcode colors for each theme.

[aeschli]

I'm expanding the issue to 'variables' and 'references'