Fixes#3119
ConEmu and iTerm2 both use OSC 9 to implement different things. iTerm2
uses it to implement desktop notifications, while ConEmu uses it to
implement various OS commands.
Ghostty has supported iTerm2 OSC 9 for a while, but it didn't (and
doesn't) support ConEmu OSC 9. This means that if a program tries to
send a ConEmu OSC 9 to Ghostty, it will turn into a desktop notification.
This commit adds parsing for ConEmu OSC 9 progress reports. This means
that these specific syntaxes can never be desktop notifications, but
they're quite strange to be desktop notifications anyway so this should
be an okay tradeoff.
This doesn't actually _do anything with the progress reports_, it just
parses them so that they don't turn into desktop notifications.
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.
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.
- Cap the total number of requests at twice the maximum number of
keys (currently 263, so 526 requests). Basically you can set and then
query every key in one message. This is an absurdly high number
but should prevent serious DOS attacks.
- Clarify meaning of new hex color codes.
- Better handle sending messages to the renderer in a way that should
prevent deadlocks.
- Handle 0-255 palette color requests by creatively using non-exhautive
enums.
- Fix an error in the query reply.
Kitty 0.36.0 added support for a new OSC escape sequence for
quering, setting, and resetting the terminal colors. Details
can be found [here](https://sw.kovidgoyal.net/kitty/color-stack/#setting-and-querying-colors).
This fully parses the OSC 21 escape sequences, but only supports
actually querying and changing the foreground color, the background
color, and the cursor color because that's what Ghostty currently
supports. Adding support for the other settings that Kitty supports
changing ranges from easy (cursor text) to difficult (visual bell,
second transparent background color).
OSC 133 defines distinct continuation (c) and secondary (s) prompt
kinds. They're both treated as prompt continuations but have different
semantic meanings: `c` allows the user to "go back" and edit previous
lines, while `s` does not.
We don't (yet) handle this "editable" distinction, but this change makes
our OSC parser slightly more correct.
Default colors are those set by the user in the config file, or an
actual default value if unset. The actual colors are modifiable and can
be changed using the OSC 4, 10, and 11 sequences.
The osc_string state of the parser limited accepted bytes to 0x7F. When
parsing a utf-8 encoded string as part of an OSC string, the parser
would encounter an error and abort the OSC parsing, allowing any
remaining bytes to be leaked (possibly) as printable characters to the
terminal window.
Allow any byte in the range 0x20 - 0xFF to be accepted by osc_put. Add
test cases which conflict with the 'anywhere' transitions (IE the utf8
sequence includes C1 control codes which might transition to another
state).
* Change state names to more human readable query_default_fg/bg
* Single-line state prongs
* String terminator is not an enum
* Removed `endWithStringTerminator` and added nullabe arg to `end`
* Fixed a color reporting bug, fg/bg wasn't correctly picked
These OSC commands report the default foreground and background colors.
Most terminals return the RGB components scaled up to 16-bit components, because some
legacy software are unable to read 8-bit components. The PR follows this conventions.
iTerm2 allow 8-bit reporting through a config option, and a similar option is
added here. In addition to picking between scaled and unscaled reporting, the user
can also turn off OSC 10/11 replies altogether.
Scaling is essentially c / 1 * 65535, where c is the 8-bit component, and reporting
is left-padded with zeros if necessary. This format appears to stem from the XParseColor
format.
Quoting from the XTerm documentation:
The first, Pc, may contain zero or more characters from the set c, p, q,
s, 0, 1, 2, 3, 4, 5, 6, and 7. It is used to construct a list of
selection parameters for clipboard, primary, secondary, select, or
cut-buffers 0 through 7 respectively, in the order given. If the
parameter is empty, xterm uses s 0 , to specify the configurable
primary/clipboard selection and cut-buffer 0.
See https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
This adds support for OSC 52 -- applications can read/write the clipboard. Due to the security risk of this, the default configuration allows for writing but _not reading_. This is configurable using two new settings: `clipboard-read` and `clipboard-write` (both booleans).
