The Ghostty implementation of OSC 21 (Kitty color protocol) currently responds to *all* OSC 21 sequences. It should not respond to a set, nor a reset command. Fix the implementation so that we only respond if a query was received.
The renderer must track if the foreground, background, and cursor colors are explicitly set by an OSC so that changes are not overridden when the config file is reloaded.
The kitty color report response is an OSC, not a CSI, so change `[` to
`]`. Colors which are unset should be reported with `{key}=`.
Make the foreground_color and background_color fields in the Terminal struct optional values so that we can determine if a foreground or background color was explicitly set with an OSC 10 or OSC 11 sequence. This makes the logic a bit simpler to reason about (i.e. `foreground_color` is now always "the color set by an OSC 10 sequence" while `default_foreground_color` is always "the color set by the config file") and also fixes an issue where an OSC 10 or OSC 11 query would not report the correct color after a config update changed the foreground or background color. The `cursor_color` field was already optional, with the same semantics (it is only non-null when explicitly set with an OSC 12) so this brings all three of these fields into alignment.
Related #2755 From the mode 2031 spec[1]: > Send CSI ? 2031 h to the terminal to enable unsolicited DSR (device status > report) messages for color palette updates and CSI ? 2031 l respectively to > disable it again. > > The sent out DSR looks equivalent to the already above mentioned. This > notification is not just sent when dark/light mode has been changed by the > operating system / desktop, but also if the user explicitly changed color > scheme, e.g. by configuration. My reading of this paired with the original discussion is that this is meant to be sent out for anything that could possibly change terminal colors. Previous to this commit, we only sent out the DSR when the actual system light/dark mode changed. This commit changes it to send out the DSR on any operation that _may_ change the terminal colors. [1]: https://contour-terminal.org/vt-extensions/color-palette-update-notifications/#example-source-code
When an empty string is given to OSC7, the pwd is reset to nil (as if the terminal never received a pwd report to begin with). This is analogous to how OSC0/2 reset the title to nil when given an empty string. This is practically useful for macOS because it allows our proxy icon to also be reset instead of being stuck on the last known path. This breaks from any known terminal behavior. As far as I can find, this is totally unspecified so we're somewhat free to do what we want. I don't think any terminal programs depend on this behavior, so I think it's safe to change it.
pwd changed apprt action, macOS app sets proxy icon based on this
Fixes #2651 First, our OSC parser didn't allow blank OSC 0 or 2 requests. This should be allowed and this fixes that with a test. Second, it seems many terminals (iTerm2, Kitty) treat setting a blank title as resetting to whatever the default title is rather than explicitly setting it as blank. If a program wants a title to be blank they should send a single space. This commit follows this behavior.