Per-project themes (multiple active themes)

[norman784]

Check for existing issues

• [X] Completed

Describe the feature

I would love to customise the theme per project, the local settings does not support this override at the moment.

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[notpeter]

Interesting. I don't see this being an immediate priority, but it'd definitely be nifty to be able to visually differentiate between multiple open projects based on theme / color of the window.

I don't think it would make sense to specify theme overrides in a project specific .zed/settings.json because then any collaborators on that project would then be forced to use the same theme overriding their personal theme selections.

So this would be in a user's ~/.config/zed/settings.json with something like:

    "theme_override": {
        "proj1": "Solarized Dark",
        "proj2": "Solarized Light"
    }

Or were you thinking it'd be explicit override for a portion of a given theme?

    "theme_style_override": {
        "proj1": {
            "element.background": "#0b342d"
        }
    }

[norman784]

I don't think it would make sense to specify theme overrides in a project specific .zed/settings.json because then any collaborators on that project would then be forced to use the same theme overriding their personal theme selections.

I didn't consider that scenario, but also I usually do not commit my editor preferences to the repository, because not everyone in a team uses the same editor.

[notpeter]

Note I altered the title from theme override to reduce confusion.

There is an existing, similar but unrelated, experimental setting named theme_overrides:

  "experimental.theme_overrides": {
    "editor.background": "#000000"
  },

Doesn't help you (only works in global .zed/settings.json) but somewhat related.

[markiol]

Would love to see that feature as well! Apparently, the last one to switch from vscode! I use two separate vscode projects for an api and a frontend, so It's really easy to distinguish between open projects based on the editor theme

[EliantenHolder]

This is a core part of my dev process too, I normally use a VSCode plugin called Peacock to differentiate editor windows currently (especially useful when working with multiple versions of the same codebase). So anyway to set different themes for different project/folders would be appreciated. I tried setting a theme in a project specific settings.json but it did not give the desired effect.

[tino]

Second that on the Peacock extension. If I could just give the top bar a different colour (via local .zed/setting.json is fine for me) that would make it much easier to recognise which of the 3-4 open Zed windows I need!

[gdamore]

I have a few different projects, and also different repos that are clones of the same project but different base branches. Colors or themes could help me when I have 3 or 4 different editor windows up!

[FelipeEmos]

Hi, folks!

This feature is very dear to me... this is probably the last thing I miss from VSCode and I think there's an opportunity here to do even better (than VSCode). 🌱

As @notpeter pointed out, making the local project config override the theme messes up other collaborators' theme config. So it's really best for it to be a "user specific config" that selects which project you are on and overrides it how you want

Let me try to help stir the discussion into some points...

Settings Blending

Zed already has some kind of "settings blending algorithm" that combines 3 settings, right?

• Default Settings
• User Settings: ~/.config/zed/settings.json
• Project Settings: ./.zed/settings.json

These 3 override each other in that order and it seems like the tech is almost already in place, cus that's what we want. It would be a matter of adding one more to the pipeline:

• Default Settings
• User Settings: ~/.config/zed/settings.json
• Project Settings: ./.zed/settings.json
• User Project Specific Settings: ~/.config/zed/settings.json ( defined in a special way )

How about that order?

Why Only Theme Overrides?

I think that's a fair question... if the Settings Blending is already in place why make this feature a Theme Specific one?

I guess treating it as just one more step of the Settings Blending pipeline could be easier to reason, to implement and to please some other power users that might do other stuff in the future. Am I right or I'm just ignorant about something 😅 ?

User Project Specific Settings

Some suggestions

Object Approach

{
  "project_override": {
    "cat_project": {
      "project_path": "~/Development/cat",
      "icon_theme": "Catppuccin Macchiato",
      "theme": {
        "mode": "system",
        "light": "Catppuccin Frappé",
        "dark": "Catppuccin Macchiato"
      }
    },
    "tokyo_project": {
      "project_path": "~/Development/tokyo",
      "icon_theme": "Material Icon Theme",
      "theme": {
        "mode": "system",
        "light": "Tokyo Night Light",
        "dark": "Tokyo Night Storm"
      }
    }
  }
}

Array Approach

This is interesting cus maybe the "Order" of overrides can appeal to some users. I don't know if someone wants to have multiple overrides

• Like some defaults for every project inside a FOLDER but being more specific at will

{
  "project_override": [
    {
      "match_path": "~/Development/cat",
      "icon_theme": "Catppuccin Macchiato",
      "theme": {
        "mode": "system",
        "light": "Catppuccin Frappé",
        "dark": "Catppuccin Macchiato"
      }
    },
    {
      "match_path": "~/Development/tokyo",
      "icon_theme": "Material Icon Theme",
      "theme": {
        "mode": "system",
        "light": "Tokyo Night Light",
        "dark": "Tokyo Night Storm"
      }
    }
  ]
}

KeyMap Configuration Inspired

The Keymap config is very nice because it separates the Context from the Bindings and it's a great structure. Maybe there's already some Tech in-place that can leverage a config like the following? Nonetheless I enjoy the ergonimics...

{
  "projects": [
    {
      "match": "~/Development/cat",
      "overrides": {
        "icon_theme": "Catppuccin Macchiato",
        "theme": {
          "mode": "system",
          "light": "Catppuccin Frappé",
          "dark": "Catppuccin Macchiato"
        }
      }
    },
    {
      "match": "~/Development/tokyo",
      "overrides": {
        "icon_theme": "Material Icon Theme",
        "theme": {
          "mode": "system",
          "light": "Tokyo Night Light",
          "dark": "Tokyo Night Storm"
        }
      }
    }
  ]
}

👆🏻 This last one is my favorite

Let's chat

I hope this helped 😉 Maybe we can address the specs and their implications to make it easier to develop Any feedback is super welcome

[a-c-m]

This is a blocker for my adoption of Zed, as i work in many codebases at once (thanks to claude, but also to allow me to switch context quickly).

I would love to see the ability to use the .zed/settings.json in a project to set the theme and or respect the "experimental.theme_overrides".

To @FelipeEmos's point above, could we take a leaf out of .env's book and use a ./.zed/settings.local.json? Or even an option/flag in your ~/.config/zed/settings.json for ignoreProjectSettings or overruleProjectSettings?

[dlight]

I like both having local settings on .zed inside the project (meant to be put on either .gitignore, or .git/info/exclude if you can't commit the .gitignore file) but also have overrides on ~/.config/zed. The former is decidedly more useful and preferable, but putting this on your home avoids changing the files in a project you would rather not touch.

[FelipeEmos]

Hi, folks!

I took a stab at this problem and created a PR for it!

• https://github.com/zed-industries/zed/pull/40418

It's not ready yet, it's a proof of concept but it Kinda works! Here's how it went in terms of Schema

// settings.json
{
  "workspace_profiles": {
    "foss": {
      "path": "~/projects/FOSS/*",
      "theme": "Dracula Solid"
    },
    "timetravel": {
      "path": "~/projects/FOSS/timetravel",
      "theme": "Ayu Light"
    }
  },
}

And here is a video I made for it:

• It's on YOUTUBE
• It has 6 min and is too big for Github
• https://www.youtube.com/watch?v=xDXLiVV8bhE

Any help would be immensely appreciated as I lack the skills to make it evolve from POC to something stable and well architected ( keeping in mind specially the state management of Zed )

Oh I underestimated the rabbit hole hahaha 🚀 let's go

[teszerrakt]

Same issue here - I maintain two clones of the same repo for parallel feature work and on-call support. Without visual differentiation, I've already committed to the wrong branch a few times. This is a safety feature, not just aesthetics.