Color problems after #10554

[telemachus]

Issue Description

After #10554, my colors have changed in ways I don't understand. This may be my problem or the problem of some of the other tools I use, but the most obvious problem is that 231 (white) has become black! See screenshot below (taken with the minimal config listed below). 231 is the black square directly above 237.

Please let me know if I can do anything else to help debug this.

Expected Behavior

Color 231 (white) should be white.

Actual Behavior

Color 231 (white) is now black.

Reproduction Steps

1. Open Ghostty.
2. Run this colortest.

   for i in {0..255} ; do
       printf "\x1b[48;5;%sm%3d\e[0m " "$i" "$i"
       if (( i == 15 )) || (( i > 15 )) && (( (i-15) % 6 == 0 )); then
           printf "\n";
       fi
   done

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0-main+cc05f64a4

Version
  - version: 1.3.0-main+cc05f64a4
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS 26.3

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

# black
palette = 0=#000000
# dark red
palette = 1=#800000
# dark green
palette = 2=#194a1f
# dark yellow
palette = 3=#808000
# dark blue
palette = 4=#000075
# dark magenta
palette = 5=#8b008b
# dark cyan
palette = 6=#469990
# grey
palette = 7=#c5c6c8
# dark grey
palette = 8=#737373
# red
palette = 9=#d20f2c
# green
palette = 10=#3cb44d
# yellow
palette = 11=#ffe119
# blue
palette = 12=#4363d8
# magenta
palette = 13=#f032e6
# cyan
palette = 14=#42d4f4
# white
palette = 15=#ffffff

shell-integration-features = no-cursor,title,sudo

# Base colors and cursor styles.
background = #ffffff
foreground= #090909

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[00-kat]

The gradients look reversed, my quick guess is that light mode isn't handled correctly…? cc @jake-stewart.

[telemachus]

Thanks for the quick answer. I didn't mention this, but I am color blind. As such, I don't really trust my instincts on color, and I didn't realize that there was a more general reversal. But the white = black definitely jumped out at me.

[jake-stewart]

Hi @telemachus

This was caused by the new 256-color palette generation. You can read the motivation behind this change here.

The extended palette is generated by default but manually set colors are never replaced. You can put palette-generate = false in your config to disable the feature entirely.

The gradients are reversed for light mode but this is completely on purpose. (@00-kat)

Color 16 should not be thought of as black. Instead, it is the background with no shades of color applied. For a black terminal, this does end up being black. For a white terminal, it should be white.

This framing difference allows the palette to be used semantically. For example, you may want a subtle red background to indicate deletion, caution or error. In the gist I showed an image composed of many themes, showing the palette being used in a diff viewer:

I understand that you are colorblind but hopefully you can recognize the consistency between the background and subtle shades of red, green, and grey.

[telemachus]

I understand that you are colorblind but hopefully you can recognize the consistency between the background and subtle shades of red, green, and grey.

Honestly, I cannot. (The screenshot you've posted is unreadable to me. It's just color soup. Not an insult or a complaint, but I don't see what you mean.) That said, if I can opt out, I'm fine. (I'm not sure if the docs have been updated, but I searched for this on Ghostty's webpage, and I couldn't find how to opt out. That should definitely be clearer—maybe with a warning for people with color-vision problems.)

Thanks for your reply.

[00-kat]

The tip docs don't seem to be updated yet apparently, but note that you can always pull up a local version of the docs which uses the docs for your version of Ghostty.

[telemachus]

note that you can always pull up a local version of the docs which uses the docs for your version of Ghostty.

Great tip: thank you. It's in there, and I appreciate the pointer for future cutting-edge things.

[mitchellh]

@jake-stewart At the same time, I want to make sure that the semantic expectation of palette usage for prior programs is retained. I'm also struggling to fully understand your comment here so I may be misunderstanding, but if the legacy terminal ecosystem does think about color 16 as black, then we shouldn't change that too dramatically. My understanding of the palette generation was that we do keep the general shape of the colors, just align them better with the base16 ones. More understanding is required on my part but just want to ask about this and challenge it a bit.

[matkozak]

#10554 fixes a problem I've had with Neovim: it's impossible to explicitly tell Neovim to use the background and foreground colors of the terminal emulator. Under the new regime those just become hard coded as 16 and 231; likewise for the grayscale ramp where you can estimate the distance from foreground & background based on the number. Nice for moving forward.

However, it's worth noting that the standard assumption is that 16 is black, 231 is white, and the grayscale ramp goes from "almost black" to "almost white". Under the new regime both the values and the direction of the ramp (and the cube) depend on the theme. Not nice for backward compatibility.

[mitchellh]

Okay, okay, thanks for all the context here. Here's kind of where I'm thinking.

Conceptually, I think @jake-stewart's arguments for color 16 and so on make sense. I get what he's saying. It does, however, break a lot of assumptions of the cube/ramp direction. And I think things like the link to Wikipedia that showcase the palette highlight this because I think people will semantically think black (for n=16) and not background. There's nowhere I can find that says to consider the 256 color palette 16-231 as "background => foreground".

That is unfortunate for reasons stated by @jake-stewart, but I think backwards compatibility is important here. We can't introduce new, useful semantic meaning onto an existing very old protocol that is widely used.

There is a new, relatively widely adopted protocol for light/dark mode detection. I think the best we can do is document that those programs should detect this and invert the palette themselves. I know that puts more work on the program, and @jake-stewart's approach would make this work automatically, but I still don't think the 256 palette -- being so legacy -- should break legacy programs by default.

I can see there being space for some kind of new sequence that tells the terminal that "hey, I want a semantic palette" or something, that is better adjusted to themes automatically. But, I don't think we should this by default.

So my concrete proposal is to eliminate the inversion and bg => fg ramp and do a more typical dark => light ramp (still taking into account bg/fg, but keeping 16 black and 231 white). I think this is the only way we can really make this a default on feature. I think this would address all the negative reactions we've gotten to it.

Open to thoughts here.

[jake-stewart]

@jake-stewart do you have examples of apps that mix colors 0-15 and 16-255
and expect them to blend nicely? I saw the screenshots in your gist, but
curious what apps they're from and what settings were used.

The image in the gist is my Neovim rendering a diff. It helps demonstrate what
can be gained with the 256 palette (while keeping the many benefits of base16).

You do not see this more often because the default palette clashes with users'
base16 themes.

I must reiterate: the default palette is not a standard. It is a theme with
many downsides covered in the gist.

Changing this theme is not a breaking change. It will change how those Vim
themes look, but they will remain perfectly usable and semantically correct.

If people want the xterm theme, they can have it by disabling palette
generation.

The average user, though, does not want the xterm theme. They want the theme
explicitly defined by their base16 colors.

[jcollie]

I have to say that I disagree with "changing this theme is not a breaking change". The 256 color palette may not be a "standard" in the sense that some formal committee argued about it for a couple of years and then issued some report that you have to buy from some organization for $250 each. It's a standard because it's the way it's been done for 40+ years.

So much of what terminals do is not defined by formal standards. A lot of the time we're digging into the XTerm source code and copying that.

So users will absolutely see this as a breaking change (as evidenced by this discussion and others here and on the Discord server).

The average user, though, does not want the xterm theme. They want the theme
explicitly defined by their base16 colors.

What evidence do you have for this statement? Previously, if a user chose a theme that defined only the first 16 colors that implicitly meant that they got the XTerm colors for colors 16-254 and they seem to be fine with that. That may have in fact been the theme designer's intent.

[jake-stewart]

I have to say that I disagree with "changing this theme is not a breaking
change". The 256 color palette may not be a "standard" in the sense that some
formal committee argued about it for a couple of years and then issued some
report that you have to buy from some organization for $250 each. It's a
standard because it's the way it's been done for 40+ years.

I agree that the xterm 256-color theme is widely used and a de facto standard
by that definition. I just wanted to emphasise that "breaking
standards-compliant terminal emulation" should not be held against this
feature since the XTerm source explicitly mentions there are no standard
colors.

I think this discussion boils down to whether losing the exact look of some
256-color themes is worth the advantages of generating the palette.

I think the sacrifice is worth it for the many reasons mentioned in the gist. I
believe it should be a default so that the terminal ecosystem may move towards
a more diverse palette as a whole while preserving backwards-compatibility.

The average user, though, does not want the xterm theme. They want the theme
explicitly defined by their base16 colors.

What evidence do you have for this statement? Previously, if a user chose a
theme that defined only the first 16 colors that implicitly meant that they
got the XTerm colors for colors 16-254 and they seem to be fine with that.
That may have in fact been the theme designer's intent.

The disregard for the 256-color palette says a lot about how users feel about
it. It is rarely used except for some pre-truecolor themes. Someone posted my
gist to Hacker News and it was met with strong approval.

[danielwe]

It will change how those Vim
themes look, but they will remain perfectly usable and semantically correct.

It's unclear to me what semantically correct means here. A user installs a vim colorscheme and gets very different colors from what the theme advertised, like in the post below: #10852 (comment). In what sense is what they're getting correct?

It is rarely used except for some pre-truecolor themes.

This can be framed as a good argument for at least not breaking these existing uses.

I think this work is really cool, but I'm starting to think it should be opt-in rather than opt-out. A non-xterm 256 palette is currently only desirable for people who are experimenting with novel, more semantic use of the palette (as you seem to be doing in your neovim config?), while breaking vim for people who are using the same venerable theme they've used for decades.

[jake-stewart]

I think we understand both viewpoints and it comes down to what we value more. None of us are wrong, we just disagree on what is more important.

I will try to leave it here so I don't add too much noise.

[dalbertom]

Bringing #10554 (comment) to the main discussion as another data point.

For me it changed my tmux colors unexpectedly. Not a big issue, I can choose a different color, but I had my status bar set to the color Eigengrau #16161d and now it's light gray. The idea of having a color that is black for a black terminal and white for a white terminal is really interesting, though, I'd be open to exploring that as well.

Original:

After #10554

My tmux config for the theme is as follows:

set -g status-bg '#16161d'
set -g status-fg white
set -g status-left-style 'bg=#16161d,fg=white'
set -g status-right-style 'bg=#16161d,fg=white'
set -g window-status-last-style 'bg=#16161d'
set -g window-status-activity-style 'bg=#16161d,fg=white'
set -g window-status-current-style 'bg=#16161d,fg=cyan'
set -g pane-active-border-style 'bg=default,fg=cyan'
set -g pane-border-style 'bg=default,fg=white'
set -g mode-style 'bg=white,fg=black'
set -g message-style 'bg=white,fg=black'

I'm not very familiar with the lower level terminal settings for colors, etc, but if there's more information needed I'd be happy to provide that as well.

Thanks!

[dalbertom]

The default colorscheme in vim also looks odd for words that are highlighted as typos

On Terminal:

On Ghostty:

[mitchellh]

What is your Ghostty config?

[dalbertom]

# Disable ligatures
font-feature = -calt
font-feature = -liga
font-feature = -dlig

# Font similar to Apple Terminal
font-family = "SF Mono Regular"
font-size = 11

#theme = dark:Tomorrow Night,light:Tomorrow
#theme = dark:iTerm2 Dark Background,light:iTerm2 Light Background
#theme = dark:Aizen Dark,light:Aizen Light
#theme = dark:Bluloco Dark,light:Bluloco Light
#theme = dark:Flexoki Dark,light:Flexoki Light
theme = dark:Terminal Basic Dark,light:Terminal Basic
#theme = dark:GitHub Dark Default,light:GitHub Light Default

keybind = global:cmd+alt+s=toggle_quick_terminal
keybind = ctrl+left_bracket=text:\x1b

confirm-close-surface = false

keybind = unconsumed:ctrl+a>ctrl+i=unbind

I was also overriding TERM in .bash_profile, but the behavior persists after removing it.

if [ "$TERM" = "xterm-ghostty" ]; then
  # Workaround to use screen with ghostty
  export TERM=xterm-256color
  export PATH=$PATH:/Applications/Ghostty.app/Contents/MacOS
fi

[mitchellh]

Can you try again with #10877 merged and see if this is now better by default? There's still more changes we want to make but I believe that should resolve the issue you're facing with out of the box defaults.

[dalbertom]

@mitchellh confirmed on 0eaf77d it is now better by default. Thanks!

[sunshine-syz]

I tested this after #10877. It doesn't fix my color theme issue with vim + gruvbox8.

Here is my .vimrc settings

filetype on
syntax on

colorscheme gruvbox8
set background=dark

Ghostty config

theme = Gruvbox Dark

With palette-generate = false the vim looks like

With palette-generate = true the vim looks like

[jake-stewart]

Themes are still generated with the new change except light themes are no longer inverted by default.

Your vim is rendered differently as expected but still useable which was the concern which lead to that change.

Unrelated: I wonder if you'd prefer :colo default in vim.

[sunshine-syz]

Yeah, it is still useable. But it doesn't look good anymore. I am not sure if it is because the gruvbox theme doesn't follow the convention you mentioned early.
My point here is this could still "break" some legacy theme and user experience.

Just to be clear I only noticed this in vim, the neovim seems fine.

[danielwe]

One thing you can try is adding set termguicolors to your config. Since gruvbox8 includes 24-bit RGB colors, this could/should make the theme independent of the 256-color palette and give you exactly the colors intended by the theme authors.

Guard the setting as follows if you need automatic fallback to notermguicolors on older terminals:

if has_key(environ(), 'COLORTERM')
  set termguicolors
endif

[noahskelton]

I don't have a huge amount of context of what change happened in this release, but my zsh prompt was unusually desaturated when I booted up ghostty this morning - this is outside of vim, just the home prompt, using Andromeda theme.

ghostty config:

unfocused-split-opacity = 1
window-padding-x = 7
theme = Andromeda
auto-update-channel = tip
keybind = shift+enter=text:\x1b\r
window-save-state = always
background-opacity = 1

This is how it looked before the update:

After, note how it is significantly desaturated:

Setting palette-generate = false fixed it, but intuitively this feels like incorrect default behaviour to alter the existing color theme in this way, unless i'm missing something important. I am on commit 861a9cf

[noahskelton]

I'm using powerlevel10k prompt, nothing else fancy.

[danielwe]

The powerlevel10k README provides an interesting data point about how application developers view the 256 palette (my emphasis):

Colors are specified using numbers from 0 to 255. Colors from 0 to 15 look differently in different
terminals. Many terminals also support customization of these colors through color palettes
(a.k.a. color schemes, or themes). Colors from 16 to 255 always look the same.

https://github.com/romkatv/powerlevel10k/blob/8ed1f58e082e1cce85e1d69235d1a906cf3c643e/README.md?plain=1#L1342-L1344

[jake-stewart]

This is a good use case for bright variants which are unaffected by this change.

[danielwe]

@jake-stewart It's unclear to me what you're suggesting here? Someone who was using a color in the 16-255 range (240 colors to choose from) and is unhappy with the change should have been using colors 8-15 instead (8 colors to choose from with no relation to the ones they were previously using)?

I assume you mean that colors 8-15 are the semantically appropriate choices for popping colors in a shell prompt. But isn't that tantamount to saying that everyone who were using colors 16-255 before this change were holding it wrong?

[jake-stewart]

But isn't that tantamount to saying that everyone who were using colors
16-255 before this change were holding it wrong?

I'm not saying anyone is using the 256-color palette incorrectly. The prompt
still looks correct after the change, it is just less saturated to match the
user's base16 theme. I'm pointing out that if someone specifically wants more
saturation, bright variants are available and unaffected by the palette
generation.

Whether this subtle difference is acceptable again comes down to what we
value more. You value the exact look of the 256-color palette for backwards
compatibility, while I do not mind the tradeoff.

[Kamillaova]

I updated to 504a361 yesterday (which includes 0eaf77d, ...if it was not reverted), and noticed that colors are now... Incorrect? First in micro, then in tmux over ssh (launching tmux with xterm-256color, with xterm-ghostty and xterm-direct, they're correct). Both apps, micro and tmux - are using alternate buffer. This alarmed me so much that I searched discussions specifically for alternate first, but found nothing. Then I found this discussion (by searching for colors), but even here there is no mention that the problem only exists in the alternate buffer. Or, maybe, the cause of this problem is more complex? If I manually switch to the alternate buffer with tput smcup, the problem will not reproduce. Also, tmux sets its own terminfo for processes inside it. But what about micro?

My Ghostty config:

macos-option-as-alt = left
macos-titlebar-proxy-icon = hidden
macos-titlebar-style = tabs
window-colorspace = display-p3
scrollback-limit = 1000000000
cursor-style = bar
shell-integration-features = no-cursor
theme = iTerm2 Smoooooth
font-family = Iosevka
font-size = 17
auto-update-channel = tip
keybind = alt+backspace=text:\x1b\x7f
keybind = shift+enter=text:\n

Screenshots

Inside tmux launched with TERM=xterm-256color:

And how it should look like:

Tmux launched on my laptop with TERM=xterm-256color - the same problem:

How are the colors in micro in Ghostty different now (before the update they were the same in Ghostty and iTerm2):

[jake-stewart]

Hi @Kamillaova,

How are the colors in micro in Ghostty different now (before the update they were the same in Ghostty and iTerm2):

This was caused by the new 256-color palette generation. You can read about it here.

[Kamillaova]

Yeah, I understand that, but why does this problem only occur in tmux and micro? (Maybe in some other apps too, but I haven't seen any others at the moment)

[jake-stewart]

Yeah, I understand that, but why does this problem only occur in tmux and micro? (Maybe in some other apps too, but I haven't seen any others at the moment)

Are they using the 256-color palette? Most programs just stick to base16 (especially CLI). We did not touch the base16 colors.

[Kamillaova]

Are they using the 256-color palette? Most programs just stick to base16 (especially CLI). We did not touch the base16 colors.

Hmm, probably tmux with xterm-256color TI uses such palette, and micro, always, but for me, it is pretty strange that fish prompt has incorrect colors only when launched in tmux with xterm-256color TI, and with xterm-ghostty or xterm-direct, they're correct.

And for example, opencode, which probably uses 256 color palette (...or, maybe it just uses 24bit colors?), looks the same in iTerm2 and Ghostty

[danielwe]

If opencode looks the same, it's using 24-bit RGB and/or just the 16 basic colors.

Keep in mind that tmux is a whole new terminal running inside another terminal. To use 24-bit RGB, fish needs to know that it's running in a terminal that supports it. It looks like your current combination of environment, ncurses/terminfo version, tmux config, and tmux version produces a tmux instance that does not advertise 24-bit RGB support. Thus, when fish is running in tmux, it falls back to the 256 palette.

[gurgeous]

Hi all, just chiming in here. Perhaps a bit late. I am the author of several standalone TUIs and related ansi coloring libraries, including some that do automatic theme detection. I have one non-trivial TUI that I've written in typescript, ruby, rust, go, and now zig. Zig is a pain because as far as I know there isn't (yet) a library for background color detection...

Anyway, It's easy to run into trouble with ANSI 16. As soon as you invert a color things fall apart. For example, recent versions of Codex were unreadable in certain dark palettes like solarized because it made assumptions about the ANSI 16 colors. If a behemoth like OpenAI can't make that work, who can? Sometimes you just have to bite the bullet and use ANSI truecolor. Want to show your errors as red on white? Avoid ANSI 16, use truecolor.

ANSI 256 is poorly understood and rarely used IMO. I think this is because the color set is lightly documented and inconsistently named, at least as compared to ANSI 16 and truecolor. The industry has been trained on CSS & RGB. Personally I've mainly used ANSI 256 to save bytes vs truecolor. ANSI 256 white/black speed up your app! The other important use case is fallback for terminals that don't support truecolor. Libraries like lipgloss will automatically pick the closest ANSI256 if truecolor is not supported.

I love the idea behind a custom 256 palette, but I'm worried that it will make ANSI 256 even less popular. If I can't count on white/black I'm not sure I can continue to use it.

As an aside, IMO there is tons of room for innovation with ansi coloring. Personally I would love to make theming faster and easier. The lipgloss color API is a delight but it requires many escape codes to get the job done. Plus you gotta use golang. We can do better, I think.

[mitchellh]

Thank you for your input!

[danielwe]

unreadable in certain dark palettes like solarized because it made assumptions about the ANSI 16 colors

On this, I wouldn't call it assumptions. What's happening is that Solarized deliberately disregards the intended hues of the bright ANSI colors (colors 8-15) and reappropriates them to flesh out a dark-to-light scale with background tones and regular content tones.¹ The mapping is listed here: https://github.com/altercation/solarized?tab=readme-ov-file#the-values

The idea here is that you will set up all your terminal apps with Solarized-aware themes built on this semantic remapping. A program that uses colors 8-15 assuming their ordinary meaning will look messed up. This is a deliberate choice by the
Solarized developers to shoehorn their theme into terminals, but is probably insufficiently appreciated by users. Here's a more elaborate elegy: https://blog.xoria.org/terminal-colors/

The whole Base16 family of themes² is based on the same idea: instead of 4 shades and 12 accents with hue names (green, magenta...), provide 8 shades and 8 accents with semantic names (strings, functions, keywords...). Explained here: https://github.com/chriskempson/base16/blob/main/styling.md. Once again, this will break everything unless you configure your apps with a Base16-aware scheme. This is even more radical than Solarized, as it uses colors 0-7 for the dark-to-light shades, so an unconfigured app will be broken even if it only uses those.

Incidentally, @jake-stewart's generated 256-color palette (let's call it Generate256) shares a lot of the same flavor: it can lift your terminal experience to new levels if you set up your apps with themes that are aware of the new, more semantic meaning the colors. Meanwhile, apps that ride on their conventional meaning now look wrong. Since there are few if any Generate256-aware app themes out there, I think the right call is to make the generated palette opt-in for now. If someone publishes a family of Generate256-themes for vim, tmux, shells, and other apps, and they gain some popularity, it would be worth reconsidering the default in a future version of Ghostty.

Footnotes

1. As it happens, they leave colors 9 and 13 (bright red and magenta) intact, and colors 8 and 15 (bright black and white) belong on the dark-to-light scale anyway, so it's really just 10, 11, 12, and 14 (bright green, yellow, blue, cyan) that are affected. ↩

2. By Base16 here I mean Chris Kempson's semantic remapping of ANSI 16 as per https://github.com/chriskempson/base16. Previously in this thread, people have sometimes used base16 to refer to ANSI colors 0-15 in general. ↩

[mitchellh]

I've decided, at least for 1.3.0, to keep the functionality but make it opt-in. More details here: #11067