[theming] Separate workbench theme and syntax theme

[hungys]

After upgrading to VS Code 1.12, I noticed that the workbench theme of the built-in Monokai color theme had been changed. However, I preferred the default workbench theme a lot.

But in VS Code, there are only two types of themes: Color Theme and Icon Theme, and the workbench theme is tightly coupled with the syntax theme in the Color Theme category.

In contrast, Sublime Text separates theme into color_scheme and theme in the preferences. For example, I can choose Material style for the workbench and Monokai for the syntax highlighting. Does the team have plan to separate them and let users have more flexibility to customize their editor?

By the way, I found that some of theme extensions use .json as their theme file (including the built-in Monokai), but the official documentation only mentions that we can use yo code to generate theme extension with an existing .tmTheme file. Is there any documentation for clarifying their difference and also the schema of the .json file?

[hungys]

As #25985 mentioned, maybe the theme of Integrated Terminal should also be separated. Doesn't really like how zsh's agnoster theme was rendered in Monokai theme :(

[egamma]

// CC @aeschli @bpasero

[anaganisk]

do textmate themes support workbench theming yet? or are the restricted to JSON type theme files?

[aeschli]

Workbench theming is restricted to the new JSON color theme format. But you can keep your text mate theme together with the new JSON file.
Just use the code yeoman generator and create a theme extension. As input pass in your current tmTheme.

[aeschli]

We currently have no plans to separate workbench themes and syntax themes in the UI.

[equinusocio]

Please if you do that, make it as flaggable setting. @hungys you can always customise your workbench color through settings

[anaganisk]

@aeschli I just figured out I can convert tmTheme file to JSON file, using vscode yo generator. So I guess its not much of a problem.

[hungys]

@aeschli

1. Is the JSON color theme format documented anywhere? I see most of the guides telling us to use yo code with an existing tmTheme file. In addition, how to keep them together with single theme contribution point?
2. Thanks. I hope this would be considered in future release.

@equinusocio
I know we can manually configure them, but considering for the user experience, I think there're benefits to separate them (like how Sublime Text did).

@anaganisk
How did you do that? I've tried yo code but the generated theme extension project is always composed with tsTheme file, even creating an empty project.

[equinusocio]

@hungys If you want to convert a textmate theme to json you can also use any of the online converter tools. I converted my material theme textmate to yaml and then to json because you can't convert directly XML to JSON.

[anaganisk]

@hungys
update yo generator-code to latest version

# run
yo code
     _-----_     ╭──────────────────────────╮
    |       |    │   Welcome to the Visual  │
    |--(o)--|    │   Studio Code Extension  │
   `---------´   │        generator!        │
    ( _´U`_ )    ╰──────────────────────────╯
    /___A___\   /
     |  ~  |
   __'.___.'__
 ´   `  |° ´ Y `

? What type of extension do you want to create? New Color Theme
? Do you want to import or convert an existing TextMate color theme?
  Import an existing theme but keep it as tmTheme file.
> Import an existing theme and inline it in the Visual Studio Code color theme file.
  Start fresh

select the second option

> Import an existing theme and inline it in the Visual Studio Code color theme file.

and copy the existing tmTheme as usual by file or link

[equinusocio]

I noticed that some scopes are different form textmate, so you have to do a full check fo the xml.

[hungys]

@anaganisk
Thank you. Seems that I installed generator-code just few hours before the latest release...LOL I now have the new option to do that :)

@equinusocio
You can check the latest Yo generator. It can convert tsTheme to json automatically now.

[equinusocio]

Yes i know. The problem is that some of the tmTheme's scopes are different in vsc. So the convert is not 1:1 but this is OT :)

[aeschli]

I'll have to add documentation on the format the color-theme file. But if you name your file ending with the -color-theme.json (e.g mytheme-color-theme.json) and open it in VSCode you will get tooling support (suggest, validation, hovers...).

There are basically two things to provide in the color-theme JSON:

color: a object with properties documented here: https://code.visualstudio.com/docs/getstarted/theme-color-reference

tokenColors the location of your tmTheme file, or the content of that file as JSON.

[Tyriar]

Related for the terminal, allowing a background color distinct from the panel: #24735

[FezVrasta]

Could you at least allow to apply multiple themes together and define the order of them? Doing so, a theme could simply define the syntax highlighting theme and override the one of a "complete" theme that defines all the UI colors as well.

I don't think this would be quite a big change, I could work on it by myself if you like the idea.

[lehni]

I think it's a mistake to not allow this separation.

GUI themes and syntax color highlighting are two very different concerns. Styling a GUI often has to do with making the software feel right in its context of a desktop OS along with other apps in use, while the syntax color highlighting is a question of what a programmer is used to from other editors, and will most likely try to preserve, or not suddenly strongly deviate from.

I've switched from Sublime Text 3, where I had my own syntax theme for the past 10 years, a modified version of TextMate's LAZY scheme if I remember correctly, converted over to Sublime Text 2 and then 3.

I've now tried a bunch of VSCode themes, and really like the GUI in some, and the Syntax highlighting in others. And while I can of course achieve this by manually creating a new theme, I don't understand why they're together when they're speaking of such different domains, and all they share is the fact that it's a bunch of collected colors and styles.

[equinusocio]

@lehni They're not speaking of such different domains. A theme must provide a complete user experience. UI and syntax highlighting are in the same app context. Check this theme

It provide a full custom user experience combining a custom UI and a custom color syntax that fetch the mood of the UX. They are in the same domain, they are in the same UX flow.

I agree with you that having a way to set a different syntax scheme is a must, but they are not different domains.

[lehni]

I'm not saying the two domains can't align style-wise, and some people may like this, but I personally find it more problematic if they do, as everything starts looking like one soup.

Having a separation between the UI and the code, also in terms of color, is helpful to the perception. For example, you're not setting all UI in the same monospaced font and type-size that is used for the code either, and if you did, it would be confusing because it would be harder to make a distinction between them.

[ShinobiWPS]

@shalanah You can customize almost anything specifically in VS COde, I'm doing it myself specifiyng different color/properties per-theme.
So yeah youc an have Black something and white something else it's in documentation on workbench customization section.

these are mines:

    "[Parasol]": {
      "list.inactiveSelectionBackground": "#5ec4ff",

      "editorGroupHeader.tabsBorder": "#292929",
      "editorGroup.border": "#292929",

      "tab.unfocusedInactiveForeground": "#9e9e9e",

      "sideBarSectionHeader.background": "#9e9e9e",
      "sideBarSectionHeader.foreground": "#fff",

      "tab.activeBackground": "#2eb2ff",
      "tab.activeForeground": "#fff",

      "statusBar.background": "#292929",
      "statusBar.foreground": "#e0e0e0",
      "statusBar.border": "#2eb2ff",
    },


    "[Monokai Pro (Filter Spectrum)]": {

      "editor.selectionBackground":"#818181",
      "editor.selectionHighlightBackground": "#818181",
      "editor.wordHighlightBackground":"#818181",

      "scrollbarSlider.background": "#ffffff85",

      "editorGroupHeader.tabsBorder": "#41ff70",

      "sideBarSectionHeader.background": "#4b4b4b",
      "sideBarSectionHeader.foreground": "#f1e364",

      "list.activeSelectionBackground": "#ffffff",
      "list.activeSelectionForeground": "#000",
      "list.inactiveSelectionBackground": "#ffffff",
      "list.inactiveSelectionForeground": "#000",

      "statusBar.background": "#424242",
      "statusBar.foreground": "#ffffff",
      "statusBar.border": "#41ff70",
      "statusBarItem.hoverBackground": "#47c1fa",

      "activityBar.foreground": "#ffffff",
      "activityBarBadge.background": "#41ff70",

      "tab.activeBackground": "#666666",
      "tab.activeForeground": "#ffffff"
    },

focused/unfocused is like 'hovered' or 'not'

[lexicalunit]

I prefer the Solarized Light theme for my code editing, but I want the application to look like a native macOS application. Separation of syntax and UI theme makes perfect sense.

Atom with a native macOS theme and solarized syntax:

Xcode with a solarized syntax:

With VSCode I must chose: Native macOS theme or solarized light theme. It doesn't really make any sense.

[noraj]

It is very embarrassing when you found the perfect UI theme but that the associated syntax highlight colors suck or are incomplete. As far as I remember Atom had separated UI colors and syntax colors. So a theme would be able to install a new syntax color but your are not forced to use it.

[scratchmex]

I think it would be great to separate syntax theme and UI theme as Atom does because that bring more customization to the user. I'm with @noraj, is a shame you found a great UI theme with a syntax highlight that sucks

[MostHated]

I am with everyone else. I think it is rather important to have separate application and syntax highlighting. I have a very specific setup I like to use that I use in Rider, PyCharm, I was able to set it up in Atom, hell, I was even 95% able to do it in Notepad++ but I can't do it in VS Code because the two typical themes I mix, I can only have one or the other.

[hsoto92]

Bumping this thread in case there's some hope on adding this feature? The community is asking for it.

[ShinobiWPS]

+1 for this feature,actually since almost ever editors had this feature

[Zireael]

Please allow separate syntax theme.
It could be as simple as choosing one theme for windows looks and another theme for syntax looks.

[vscodebot]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[KishorJena]

Is it under process or already rolled out. I am eagerly waiting for separate theming of Vscode Window UI and Editor Syntax

[jaycverg]

Also waiting for this. I came from Webstorm and still trying to fully switch to vscode. On my mac, I would like to use a UI theme that matches my dark UI theme but would like to use a different color scheme for my editor syntax.

[ygypt]

the year is 2091, dinosaurs have risen on earth once again, driving humans to escape to mars. the poor and unfortunate were left behind to scavenge and fend. the humans of earth fought tirelessly to stay alive, bonding together and developing the tactics to take the reptiles out. dinosaurs have gone extinct a second time, and the Meek who fled to mars leaving the poor behind are soon to feel the wrath of a planet coated in crimson with raptor blood, inhabited by warriors, and vscode still doesnt let you pick a separate theme for the ui and the syntax

[paul-hph]

Come on @smammy... :D

[ygypt]

@paul-siteway cut smammy some slack, the last time he had the freedom of choice his head blew a gasket

[rldribeiro]

Plus one for this feature.

[sirius0xff]

Currently one can first select the prefered color theme, the in run in command palette:
Developer: Generate Color Theme From Current Settings

in a generated file, copy the array after tokenColors

"tokenColors": [...]

paste into your settings.json

{//settings.json
...
"editor.tokenColorCustomizations": {
    "textMateRules": [ ... ] // <---------------------- here
},
...
}

This would fix many of the syntax theme and allow the workbench theme to be changed.

Unfortunately this does not cover semantic Token Color, which can also be edited:

{//settings.json
  "editor.semanticTokenColorCustomizations": {
    "rules": {
      ...
    },
  },
}

Or disable semantic highlighting.....

[iDad5]

Some thoughts on this:

I generally agree that it's a good thing if the UI of the workbench and the syntax highlighting is matched - good design isn't about looking nice, but about conveying information effortlessly. And there are a lot of themes out there but due to the lacking documentation on how to make a theme from scratch most of them are just based on a few others, which actually makes it very hard to find unique good ones.

The option of customizing most aspects of a theme is a good thing, but it fails at a crucial point: semantic highlighting.

If we fully separate workbench- and syntactic themes it might actually get really confusing in the end, as for legacy reasons existing and beloved color themes will have to be able to do both. (And also it seems to be rather complicated and/or the priority of/enthusiasm for this feature is not to great with the team as the time it takes to get it done is rather long...)

I would propose a different approach therefore:

Why not extend the theme syntax so that tokeColors as well as semanticTokenColors can be wrapped into language specific definitions together with a subset from colors (editor.background being the most obvious) and let those override the standards defined in the root.

it would be a combination of the language specific settings

my-color-theme.json:

 {
    "color": {"same as" : "now"},
    "colorTokens": {"same as" : "now"},
    "semanticColorTokens": {"nothing" : "new"},
    "language-specifics" : [
        {
            "[typescript]" : {
                "color": {
                    //light on dark
                    "editor.background": "#080809",
                    "editor.foreground": "#b8cbd1"
                    // and so on for relevant editor settings only
                },
                "colorTokens": {
                    // same principle as today
                },
                "semanticColorTokens": {
                    // ditto 
                }
            },
            "[markup]" : {
                "color": {
                    // dark on light
                    "editor.background": "#b8cbd1",
                    "editor.foreground": "#080809"
                    // and so on for relevant editor settings only
                },
                "colorTokens": {
                    // same principle as today
                },
                "semanticColorTokens": {
                    // ditto 
                }
            }
            // and on ...
        }
    ]
}

That in combination with ad better documentation for theming - it is actually pretty easy to extend/customize existing themes.
Could solve most of the whishes of this issue, issue #20652 which is also very popular and even longer not solved.

(If you add in #105247 allowing for color palettes - it would make things even easier.)

If I can be of assistance with this I would give my very best.