Using different themes for different windows

[afiskon]

It would be nice to have an ability to use different themes for different Zed windows.

I keep several projects open in different windows. It would be easier to navigate across them on MacOS if every project had its own theme. I would instantly recognize the project I'm looking for when switching Desktops with the touch pad (or Control+Up arrow).

At the moment it doesn't seem to be possible. When I switch the theme it is changed for all Zed windows at once.

[dlight]

For personal projects, I expected that creating a file .zed/settings.json and adding a theme config would be enough to achieve that. However, while Zed indeed recognizes that file as project-scoped settings (on mouse hover it displays tooltips like "The theme to use for light mode" etc), the theme settings get silently ignored.

The solution I would prefer is local per-project settings overrides (for things like themes, LSP behavior, etc) that lived in ~/.config/zed with a path-based config, so that different people may make different theme choices for the same project (without committing it into the project-scoped config); and generally it would be nice if config were layered like that: the global ~/.config/zed/settings.json has the least precedence, the project-scoped .zed/settings.json has more precedence, but ultimately the personal override ~/.config/zed/settings-overrides.json (keyed by project path) always wins because it has the most precedence, and so the local config of a theme per project lives there.

This file settings-overrides.json could be like this:

{
   "/home/myuser/project": { // (inline config)
      "theme": {
       ...
     },
   },

   "/home/myuser/otherproject": "/home/settings/mycustomzedoverride.json", // separate config file

   "/home/myuser/projects/*" { // (inline config, multiple directories with glob)
      ...
   }
}

(This can be just a section of settings.json too, something like "overrides": { ... })

[afiskon]

TWIMC as a workaround I ended up keeping all Zed windows on the same Desktop. When choosing this desktop I can quickly switch between windows with Command+` (the button near left Shift) in order to find the right one. After discovering this workaround I'm not certain if supporting different themes for different windows would be so beneficial after all. If this is relatively easy to implement, it would be nice to have. If not I guess it doesn't worth it, for my use case at least. Perhaps there are other cases.

[dsegovia90]

Interestingly, if you use the project level .zed/settings.json "theme": "<your theme>" it does not override the global settings. I'm interested in having multiple themes per open window as well, just to quickly identify which editor is which project.

[VojtaStruhar]

Exactly, that would be super neat. Maybe just a colored strip would be enough for me (it's not like I need one project in light mode), but just to quickly differentiate between them

[oluckyman]

Yeah, they say explicitly in the docs, that theme is not overridable.

I'm not sure why or how difficult it is to implement.
But I think having a theme per project is important, as it promotes aesthetics as a core feature of Zed. I personally switched to Zed because of the aesthetics first and only later discovered all the other great features.

[notpeter]

The lack of this feature is reflection of the current settings stack. Currently there is no way for a user to override a project settings in a repo without directly editing that file. When you use the theme selector, it writes your selection to your user settings, but since project settings will override your user settings it would have no effect.

Broadly speaking, .zed/settings.json in a project folder/repo should reflect settings which should ALWAYS apply to that project -- e.g. use these formatter settings, pass these special flags to the LSP, etc. In any project that is used by more than one person, user-specific configuration (vim_mode, theme, buffer_font_size) should be stored elsewhere.

I don't have good sense of the best way to implement this without a bunch of negative consequences. Broadly speaking, I could imagine that per-project settings overrides:

{
  "overrides": {
    "/Users/peter/code/zed": {
      "theme": "One Dark",
      "buffer_font_size": 18
    }
  }
}

Which could work for single-folder / single-file workspaces, but would break for multi-folder workspaces because there's not an easy way to identify those (e.g. "code/folder1,code/folder2") and what would happen if you added a folder to that workspace, would the theme reset? Would it update the overrides key names? (if not, adding a folder would sever existing overrides).

Similarly one could imagine a .zed/whatever_settings.json that should not be checked into source control, that applies user settings on a project basis, but what would you call it? And it would further complicate the existing settings stack:

• Default Settings (default.json in zed repo)
• Global Settings (WIP, /etc/zed/settings.json)
• User Settings (~/.config/zed/settings.json)
• Project Settings (.zed/settings.json)
• SuperUserProject Settings (.zed/super_settings.json)

Setting aside the confusion around harmonization of alternate settings sources (.editorconfig, .prettierrc.json in any folder, including parent folders to projects) you still have the UI confusion -- if I use the theme selector where does it persist those settings? Does it break if there's an override in super_settings? Same with other things which are currently stored in user settings (agent settings, vim_mode, base_keymap, etc) but can be set interactively in the UI (Error: Your super settings and user settings conflict, what do we do now?). Multi-folder workspaces might also conflict -- frontend says "one dark", backend says "one light" what should I do?

Alternatively we could stuff it into the workspace db (currently entirely opaque to the user) but that also feels dirty. My gut is that supporting such a feature a significant rethinking of settings and workspace/project state. Perhaps worth doing, but I don't see any quick wins.

Thanks for reading my ramblings. I'm open to others ideas in the space.
But for the moment, I don't see a design I'd be excited about.

There's an existing feature request for this if you'd like to upvote/subscribe:

• Per-project themes (multiple active themes) #13300

[jecarroll]

Just stumbled across this thread and thought I'd throw in my use-case (which might soon become more common):

I have been a big fan of the Zed AI agent, but I've very recently switched back to Claude Code which has come on a lot since its early beta days. My current workflow involves managing parallel Claude Code agents (currently two), working on separate branches of the same project (using git worktrees). To keep myself sane, I have taken to colour-coding my Mac Terminal windows using Terminal's theming feature. Right now I have a yellow-themed Terminal window with Claude Code working on feature A in one branch and a red-themed Terminal window with Claude Code working on feature B in another branch. The colours are really helping me keep things separate in my mind as I manage these two "employees". When I switch over to Zed to review their code, it would be great if the colour difference could be maintained. In fact, even better would be running Claude Code within Zed's built-in terminal panel, and having the whole window themed. In terms of your implementation head-scratcher above, @notpeter, my use case would need different themes for different branches of the same repo. I'd be happy enough to set these manually and ephemerally on the window, although I guess it would be neater if they could be persisted in settings somehow. Hope this is useful input! :)

[bjackman]

It doesn't address the UI concerns, but what about a .zed/settings.json that's intended to be checked in, and a .zed/settings.local.json that's intended to be .gitignored? I noticed this is how Claude Code operates and I think it's a nice simple option.

[dlight]

I think this two settings setup on each project is awesome for other settings as well (such as LSP server settings), even if in some distant future a better way of per-project theming is found.

I mean if you are editing a project that already has .zed/settings.json but you need to do some local changes to get work done, then you have to resort to performing gruesome git crimes that won't go unpunished.

[ostwilkens]

Lately I have been working in 4-5 workspaces simultaneously, and it gets confusing when every window looks similar. Assigning one theme per context would make it a lot easier to work with. I would love to be able to set theme both in the server-specific and project-specific settings file.

[Ltadrian]

pleasee can someone build this 🙏