[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: https://github.com/Microsoft/vscode/issues/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.

[zeshanshani]

Same problem here as @lehni. Been using Sublime for over 6 years now. I loved Cobalt2 theme by Wes Bos, but its syntax color highlighting doesn't match my preference.

Have you considered offering these two options yet? @aeschli - I think it's most needed for Sublime users.

Of course, I can try to adopt the new habits here but it would be wonderful if you consider offering different color highlighting theme option as an optional setting.

[zeshanshani]

@equinusocio lol, I may not use some of those features at all, but color syntax? That I have to deal with every time 😄

Just kidding though, I loved VS Code so far. Haven't tested all of its features, but it sure looks very powerful.

[leonardofaria]

@zeshanshani I am at the same case - Cobalt2 fan but don't like a dark editor.

The workaround that I did:

• I am using Cobalt2 theme
• I copied a few stuff from macOS Classic theme and I am changing manually - it is not 100% perfect however it better than keeping all the interface dark.

If you are curious, here are my settings: https://gist.github.com/leonardofaria/1f89b4a15e89a2d98db7bdd22ec99284#file-settings-json-L35

[zeshanshani]

@leonardofaria Sorry I missed your response. Thanks for the settings. Unfortunately, that didn't work for me. I was actually looking for changing the code syntax highlighting while keeping the overall look of Cobalt2 theme same. What you have is the opposite I suppose.

I kinda adopted the VS Code behavior so I'm ignoring the syntax highlighting issue. But, it'd be wonderful if they can add this feature because I love Twilight (SL) color scheme.

[leonardofaria]

@zeshanshani yeah, your approach (adding cobalt2 syntax highlighting) also works and it is probably better because Wes' theme is defined as a dark theme and the icons are high contrast-ones. I didn't find a way to revert this icon setting.

[zeshanshani]

@leonardofaria yes, it's by default dark version. I'm a huge fan of dark themes, so it works best for me. Maybe we should submit a feature request to release a light version as well with some high-res icons. :)

[190n]

Is this issue still active? I'd really appreciate this feature.

I use Linux. On Linux, VS Code can't change the color of the titlebar, so almost all themes look wrong:

I can work around this using some themes that match the colors of common GTK themes. But this is far from ideal. I can't have a separate syntax highlighting theme; I'm stuck with whatever the author of that extension chose.

[Tyriar]

@190n we added the workbench.colorCustomizations setting to override whatever theme keys you want. If you can theme the title bar on Linux (I'm not 100% sure), then you should be able to do it here.

[190n]

Sorry, didn't notice that. Thanks for the quick reply!

[shalanah]

Hi, I'm trying to make the switch from Brackets to VSCode, it has been a long time coming... and hard since I love Bracket's UI so much. I've been trying to recreate Bracket's UI generally speaking in VSCode. Brackets has a dark nav area and a light editor area as one of its themes.

I'd really love if you could separate editor light/dark from the rest of the UI light/dark (sidebar nav etc), or make those elements that are tied to uiTheme easily accessible in theming or workbench.colorCustomizations.

I especially notice this issue with some btns that are tied to uiTheme (mostly on hover, ie: in source control and hovering over a file name there are a couple of icons that appear only on hover) and the editor text cursor color. It seems that you can get the btn colors to work or the text cursor (contrast wise) but not both since they are tied to uiTheme.

[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[bot]]

:slightly_smiling_face: 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](https://aka.ms/vscode-issue-lifecycle). 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.