Repository navigation
config: disable palette-generate by default - #11067
Merged
Merged
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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=trueif 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