Support dark and light themes and syncing theme to system setting, a la window decorations

[sloane-shark]

Several other popular terminals support the ability to configure independent themes for dark and light mode, which will then be automatically selected according to the system's dark or light mode setting. Ghostty already supports syncing the light or dark value of the window decorations with the system setting, so I imagine we could leverage the same logic for themes.

For a little bikeshedding, since themes are just configurations, I think it would probably make sense to introduce light-config-file and dark-config-file for arbitrary configuration files that are loaded and unloaded according to the system setting. This would allow adjusting other settings if desired, such as fonts or transparency.

[rockorager]

Contour has written a VT extension to notify applications using escape sequences that a color scheme change occurred. Would be good to include this reporting as part of this feature

Reference

[mitchellh]

Contour has written a VT extension to notify applications using escape sequences that a color scheme change occurred. Would be good to include this reporting as part of this feature

I would like to keep these separate and focus this issue on the process of configuring Ghostty with theme-specific configurations. I agree with supporting this once it has settled a bit though.

[mitchellh]

Sharing some prior thinking I've had on this. None of this is set in stone, its not a mandate. Just thoughts.

From a design perspective, I think its important that Ghostty retains the property that the CLI arguments and configuration format is isomorphic. I've personally always enjoyed it when software has had that property, because its easy to move stuff around between files and scripts. For those unaware, every Ghostty configuration key is also a valid CLI flag, and the format is identical. The config lines just don't have the -- prefix a CLI flag has.

So, I'd like to retain that property.

I think the suggestion OP has around light-config-file and dark-config-file is not bad, because it does retain that to some extent, but one issue is that you can then only set themed configurations within files, not directly on the CLI.

An approach I was trying to consider was the ability to annotate any config key with a condition in which it is active. For example: background = FF0000 [theme=dark]. This is just an example, not literal proposed syntax. Then in the CLI you could do --background="FF0000 [theme=dark]". I don't love that syntax but the idea I think is more important. This approach would also still enable the dark/light config file because you could do config-file = my-dark-config [theme=dark].

The condition proposal also would let us introduce other conditions. For example, I share my identical Ghostty config between macOS and Linux, and I'd love to have some Linux-specific keybindings. It'd be nice to do keybind = something [os=linux] or whatever.

The condition proposal could also easily extend into AND, OR conditions, although there is no need to introduce that complexity today. I'm merely pointing out the framework allows for it.

🚲🏠 (Bikeshed): We could also bake the condition into the key, i.e. background[theme=dark] = FF0000. This becomes clunkier on the CLI because you'd have to quote the entire thing including the --. Perhaps there are other approaches.

[erf]

Regarding themes, Wezterm ships 700+ iTerm2 themes, is this something Ghostty will do too (or can be inspired by) ?

[mitchellh]

Regarding themes, Wezterm ships 700+ iTerm2 themes, is this something Ghostty will do too (or can be inspired by) ?

Again, I'd like to not make that a focus of this issue, but we could definitely ship those as part of the resources directory. There are already over 250 Ghostty themes available here: https://github.com/mbadolato/iTerm2-Color-Schemes (Ghostty being one of the formats available)

[mitchellh]

Note with #942 we now have built-in themes set with theme. (Not merged at the time of writing this comment because I'm waiting on an upstream PR but I expect that'll happen soon) This configuration will fit very nicely with the ideas proposed in this issue.

[sloane-shark]

i've been meaning to sit down and hash out some alternate syntax proposals for this, but have been busy. re your latest bikeshed method, i'm not sure we WOULD have to quote so aggressively, at least in all cases... i think most shell parsers would let us get away with something like --[mode=dark]theme=my-theme on the CLI, we would just have to implement the splitting by hand. i think that might already be what is done, anyway?

[mitchellh]

i think that might already be what is done, anyway?

Yep!

Happy to hear more bikeshed ideas, I think I've enumerated my constraints/desires clearly above but feel free to ask any Qs.

[adamcstephens]

I've used external scripts with kitty to provide light/dark toggling. Kitty has a subcommand to set individual colors, or it can load them from a file (e.g. a theme file).

The subcommand even has other options for targeting all windows, how new windows are handled, etc. For my purposes I've been happy with just sending the theme change to all terminals.

Adding concepts for light and dark are nice, but maybe just on-the-fly loading of a theme file could go a long way towards enabling that.

Usage: kitten @ set-colors COLOR_OR_FILE ...

Set the terminal colors for the specified windows/tabs (defaults to active
window). You can either specify the path to a conf file (in the same format as
kitty.conf) to read the colors from or you can specify individual colors, for
example::


kitten @ set-colors foreground=red background=white

[gagbo]

Adding concepts for light and dark are nice, but maybe just on-the-fly loading of a theme file could go a long way towards enabling that.

I think I’d prefer that as well, I don’t know how easier/harder it would be to configure. My sole usecase for "quick theme switching" is actually runtime cursor color switching. When I switch my editor from light to dark theme, I’d like to have a quick command (shelling out is ok) to change the cursor color from dark to bright.

(Bear with my slow typing in the small demo)

Enregistrement.de.l.ecran.2024-05-14.a.12.02.36.mov

[roguesherlock]

Adding concepts for light and dark are nice, but maybe just on-the-fly loading of a theme file could go a long way towards enabling that.

I think I’d prefer that as well, I don’t know how easier/harder it would be to configure. My sole usecase for "quick theme switching" is actually runtime cursor color switching. When I switch my editor from light to dark theme, I’d like to have a quick command (shelling out is ok) to change the cursor color from dark to bright.

(Bear with my slow typing in the small demo)

Enregistrement.de.l.ecran.2024-05-14.a.12.02.36.mov

I have this autocommand in my neovim config which switches the ghostty theme. I just have to then press cmd+shift+, to reload. Thought I'd share in case it's helpful until we have proper theme syncing,

vim.api.nvim_create_autocmd("ColorScheme", {
  pattern = "*",
  callback = function()
    if vim.o.background == "light" then
      if term == "xterm-kitty" then
        vim.fn.system("kitty +kitten themes " .. M.terminal_theme_light)
      elseif term == "xterm-ghostty" then
        vim.fn.system(
          "sed -i'.bak' 's/theme = .*/theme = "
            .. M.terminal_theme_light
            .. "/' (readlink ~/.config/ghostty/config)"
        )
      end
    elseif vim.o.background == "dark" then
      if term == "xterm-kitty" then
        vim.fn.system("kitty +kitten themes " .. M.terminal_theme_dark)
      elseif term == "xterm-ghostty" then
        vim.fn.system(
          "sed -i'.bak' 's/theme = .*/theme = "
            .. M.terminal_theme_dark
            .. "/' (readlink ~/.config/ghostty/config)"
        )
      end
    end
  end
})

[i-am-linja]

I think, given we have built-in themes, an MVP would be separate theme-light and theme-dark options, and automatic switching. Reactive config loading is nice, but seems overkill if it's just for colours.

[net]

Unless I'm missing something, themes are built into the release, so theme-light and theme-dark wouldn't work for user themes.

[i-am-linja]

Unless I'm missing something, themes are built into the release, so theme-light and theme-dark wouldn't work for user themes.

Under the current system, they would not. However, the current system is a bad fit for theme switching anyway: see above, where an entirely separate config seems like a sensible solution. Ideally we would have theme = ./user-theme-file, but that's a separate idea which does not block the MVP.

[mitchellh]

Since #2089, users can provide custom themes. This doesn't fix this issue at all but I'm just noting this as response based on the previous comments.

[gpanders]

Brainstorming another idea for conditional configuration directives (see this comment):

Zig's build-exe command configures module options by first using the -M flag, which starts a new set of module options, followed by a set of module-specific flags like -target, -O, etc. So for building multiple modules, the usage would look roughly like zig build-exe -Mfoo=foo.zig -O Debug -fstrip -Mbar=bar.zig -O ReleaseSmall.

Ghostty could do something similar, which would allow it to work for both the command line and config file. Essentially, rather than annotating individual options, options are grouped based on a condition. Hypothetical example:

Command line

ghostty \
    --if=os=linux \
    --command=/usr/local/bin/fish \
    --keybind=alt+left_bracket=goto_split:previous \
    --keybind=alt+right_bracket=goto_split:next \
    --if=os=macos \
    --command=/opt/homebrew/bin/fish \
    --if=theme=dark \
    --background=#ff0000 \
    --if=theme=light \
    --background=#00ff00

Config file

if = os=linux
command = /usr/local/bin/fish
keybind = alt+left_bracket=goto_split:previous
keybind = alt+right_bracket=goto_split:next

if = os=macos
command = /opt/homebrew/bin/fish

if = theme=dark
background = #ff0000

if = theme=light
background = #00ff00

And the conditions to if could be combined:

if = os=linux,theme=dark

background = #ff0000

if = os=macos,theme=dark

background = #fff000

It's admittedly a little unusual, but it at least solves the constraint of keeping the config file and command line isomorphic 😅

[melMass]

What would be the guidelines for proposing such a PR? I'm willing to look into it given I also have the need but don't want to waste anyones (myself included) time going in the wrong direction

[mitchellh]

Converted to a discussion since there are still a lot of vague design questions about this. Once we determine actionable tasks that we can work on we can convert those to issues.

[will]

One related thing that would be nice to go along with auto light/dark theme switching is a way to notify running programs (eg neovim) so they can also change also if needed. I don't have a concrete proposal for how to do this in Ghostty, but here's what worked for me in the past:

When I used iTerm2, I managed to get them to send SIGWINCH to running programs whenever the theme change, and then got neovim to support setting custom autocommands on receiving SIGWINCH. Those together allowed me to change neovim coloschemes as the system swapped light/dark. Normally that signal is only when the size of the terminal changes, but it's not toooo much of a stretch include colors changing.

I later moved to wezterm. With the lua scripting it has I was able to instead write out a file with the current light/dark mode whenever it changed. And then had neovim watch for changes to that file and swap colorschemes accordingly. The file was a bit inelegant, but a little easier to deal with on the neovim side than the sigwinch all-in-all.

I'm for sure not saying any of those ways are great and should be copied for Ghostty though. There's probably a half dozen ways to do this, but none are clearly superior to the others. I mostly just wanted to post this to put the idea in the back of people's heads :)

[mitchellh]

One related thing that would be nice to go along with auto light/dark theme switching is a way to notify running programs (eg neovim) so they can also change also if needed. I don't have a concrete proposal for how to do this in Ghostty, but here's what worked for me in the past:

Ghostty already supports this today. There is a previously existing terminal spec to do this and Ghostty implements it on both macOS and Linux.

See: #1444

[will]

Oh great, thank you! I had just assumed that it wouldn't yet be supported because the auto theme switching wasn't yet, so I didn't even think to search for it before writing that message. Sorry!

[zoriya]

Could we start with a basic theme support, or do we need to support the whole advanced configuration from the start?

I'd like to have something like:

theme-light = 
theme-dark = 

and if one is not specified, it would default to theme.

I actually wanted to implement that, but I always fail to edit themes more than once because it pushes them in the _replay_steps list.

I tried another approach but didn't know how to handle the "tracking of system theme" part from the Config.zig struct due to ownership concerns. I thought about adding a _systemTheme = .light | .dark in the Config to apply the correct theme- there ; but I am not sure where/when I can set this variable from a gtk/swift handler.

[mitchellh]

Could we start with a basic theme support, or do we need to support the whole advanced configuration from the start?

I'm open to this and I've said that before (I can't find where I did so let this be the new ground truth!).

I actually wanted to implement that, but I always fail to edit themes more than once because it pushes them in the _replay_steps list.

Yeah, we'd have to fundamentally rework how we load themes. I don't think it has to be a huge change, it might be as much as maintaining separate sets of steps per theme rather than fully in replay steps.

I think for actual configuration, we already have theme. I wonder if we can just change the parsing of that from <string> to something a bit more structured:

# Always 
theme = foo 

# Conditional (both are required, order doesn't matter, whitespace is trimmed)
theme = light=foo,dark=bar

That makes it so we don't need the auto-detect-color-scheme config @shayne proposed.

[mitchellh]

#2725

[shayne]

VS Code takes a similar approach. The following config enables auto theme switching:

{
  "window.autoDetectColorScheme": true,
  "workbench.preferredDarkColorTheme": "GitHub Dark",
  "workbench.preferredLightColorTheme": "GitHub Light"
}

The standard color theme config is simply:

{
  "workbench.colorTheme": "GitHub Light"
}

Applying this to Ghostty, perhaps the following:

# default, single theme
theme = Dracula

# auto scheme theming
auto-detect-color-scheme = true
light-theme = Tomorrow
dark-theme = Dracula

[jcollie]

Just spitballing here, but to support switching Ghostty's theme we would need to separate all of the settings that can be affected by a theme into a separate struct so that they can be managed independently from the config and switched in/out as needed.