mirrors/ghostty
1
0
Fork 0
mirror of https://github.com/ghostty-org/ghostty.git synced 2026-04-06 07:38:21 +00:00
Code Issues Packages Projects Releases Wiki Activity

config: disable palette-generate by default (#11067)

Browse Source 
Following the discussion at #10852, I believe this is the right default.
I'm willing to continue to revisit this decisions, but Ghostty 1.3 is
around the corner and I don't think such a change like this should be
pushed into it.

This was proposed before but I wanted to wait to iron out any bugs here
and I think we have. Namely we identified one bug where we were
accidentally overriding our _default_ palette which shouldn't happen.
But now that it has sat awhile and we've gathered enough feedback, I'm
willing to commit to it.

In general, we got **very little negative feedback.** The linked
discussion shows very little activity relative to other more
controversial changes we've made. It has basically 1 upvote with around
5 participants whereas our most popular or breaking features/bugs have
had at least dozens if not over a hundred. I think this shows that this
change isn't that disruptive, either because the colors work fine or
because not that many things use the 256-color palette (probably the
latter moreso but a mix for sure). For that reason, I do think
revisiting this at some point is warranted.

I think palette generation is best left as a _theme author_ tool. A
Ghostty color theme could include `palette-generate=true` if it wants to
customize the 256-color palette more easily. Of course, end users can as
well anytime.

Another part of my reasoning is that TUI programs who want this behavior
can already achieve it themselves by mixing dark/light theme detection
via CSI 996
(https://contour-terminal.org/vt-extensions/color-palette-update-notifications/)
with OSC 4/10/11 color query and change sequences, both of which are
decently supported in the terminal ecosystem and fully supported in
Ghostty.

I'm also open to considering some kind of new sequence to make this
easier for TUIs (probably a mode) where they can opt-in to palette
generation plus "harmonius" palettes (see `palette-harmonius`) and
Ghostty does it on demand then. I think that'd solve the legacy vs new
TUI argument where legacy programs can continue to make assumptions
about the palette and new programs can opt-in to a more dynamic palette
without having to do a lot of work themselves.

cc @jake-stewart
This commit is contained in:
Mitchell Hashimoto
2026-02-27 11:41:38 -08:00
committed by GitHub
parent 3a21305d09 c78d9cba9e
commit 705d8c61ce
1 changed files with 7 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
src/config/Config.zig
View File

@@ -802,11 +802,17 @@ palette: Palette = .{},
/// look. Colors that have been explicitly set via `palette` are never
/// overwritten.
///
/// The default value is false (disabled), because many legacy programs
/// using the 256-color palette hardcode assumptions about what these
/// colors are (mostly assuming the xterm 256 color palette). However, this
/// is still a very useful tool for theme authors and users who want
/// to customize their palette without having to specify all 256 colors.
///
/// For more information on how the generation works, see here:
/// https://gist.github.com/jake-stewart/0a8ea46159a7da2c808e5be2177e1783
///
/// Available since: 1.3.0
@"palette-generate": bool = true,
@"palette-generate": bool = false,
/// Invert the palette colors generated when `palette-generate` is enabled,
/// so that the colors go in reverse order. This allows palette-based