This commit changes a LOT of areas of the code to use decl literals
instead of redundantly referring to the type.
These changes were mostly driven by some regex searches and then manual
adjustment on a case-by-case basis.
I almost certainly missed quite a few places where decl literals could
be used, but this is a good first step in converting things, and other
instances can be addressed when they're discovered.
I tested GLFW+Metal and building the framework on macOS and tested a GTK
build on Linux, so I'm 99% sure I didn't introduce any syntax errors or
other problems with this. (fingers crossed)
See #5930
Kakoune sends a real SGR sequence with 17 parameters. Our previous max
was 16 so we through away the entire sequence. This commit increases the
max rather than fundamentally addressing limitations.
Practically, it took us this long to witness a real world sequence that
exceeded our previous limit. We may need to revisit this in the future,
but this is an easy fix for now.
In the future, as the comment states in this diff, we should probably
look into a rare slow path where we heap allocate to accept up to some
larger size (but still would need a cap to avoid DoS). For now,
increasing to 24 slightly increases our memory usage but shouldn't
result in any real world issues.
Fixes#5022
The CSI SGR sequence (CSI m) is unique in that its the only CSI sequence
that allows colons as delimiters between some parameters, and the colon
vs. semicolon changes the semantics of the parameters.
Previously, Ghostty assumed that an SGR sequence was either all colons
or all semicolons, and would change its behavior based on the first
delimiter it encountered.
This is incorrect. It is perfectly valid for an SGR sequence to have
both colons and semicolons as delimiters. For example, Kakoune sends
the following:
;4:3;38;2;175;175;215;58:2::190:80:70m
This is equivalent to:
- unset (0)
- curly underline (4:3)
- foreground color (38;2;175;175;215)
- underline color (58:2::190:80:70)
This commit changes the behavior of Ghostty to track the delimiter per
parameter, rather than per sequence. It also updates the SGR parser to
be more robust and handle the various edge cases that can occur. Tests
were added for the new cases.
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).
