osc.zig: undefined pointer was dereferenced when warning was issued
for handler missing
Parser.zig: too many parameters was not handled in the final case
Parser.zig: parameters being too long (>255 digits) was not handled
* 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.
Saw this on HN:
https://github.com/darrenstarr/VtNetCore/pull/14
I wanted to see if ghostty was vulnerable to it (it is not). But, its a
good example of a weird edge case in the wild and I wanted to make sure
it was redundantly tested. It looks like we read the "spec" (blog posts,
man pages, source of other terminal using tools, etc.) right.
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).
