mirror of
https://github.com/ghostty-org/ghostty.git
synced 2026-06-04 02:44:50 +00:00
c78d9cba9e
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. 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.