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).
Commit fbe030d85a80 ("terminal: respond to XTVERSION query") introduced
responding to XTVERSION queries. The implementation uses the
.write_small method, which has a limit of 38 bytes. This works well if
your branch is named "main", since the branch is part of the
version_string variable. If you start using longer branch names, you can
quickly run into the limit.
The XTVERSION response is:
"\x1bP>|ghostty d.d.d-<branch>+<12-digit-hash>\x07"
Which has an overhead of 32 bytes, meaning the natural branch limit is 6
bytes (6 characters, assuming you use ASCII branch names). Github has a
limit of 256 chars, so let's set a max XTVERSION buffer of 256+32 = 288
Fixes: fbe030d85a80 ("terminal: respond to XTVERSION query")
XTVERSION (CSI > 0 q) is used by some libraries to identify the terminal
+ version. Respond to this query with `ghostty {version_string}`. There
is no formal format for this response. A roundup of a few tested
terminals show two primary formats. This patch opts to save one byte and
use the `name SP version` semantics.
foot: foot(version)
xterm: XTerm(version)
contour: contour version
wezterm: wezterm version
Reference: https://github.com/dankamongmen/notcurses/blob/master/TERMINALS.md#notes-for-terminal-authors
Signed-off-by: Tim Culverhouse <tim@timculverhouse.com>
Fixes the next issue on windows. The fontconfig library is calling
the function xmlCreatePushParserCtxt from libxml2, however, the function
declaration was being omitted because fontconfig was not defining
the LIBXML_PUSH_ENABLED preprocessor symbol. However, instead of a
compile error, C's support for implicit function declrations allows it
to happily call the function anyway, with the wrong ABI. The main issue
was the return type being implicitly declared as "int" instead of a
pointer. On my system this was causing the return pointer to be
truncated to 32 bits and then sign-extended which caused a segfault
once it was dereferenced.
I've gone ahead and added the -Werror=implicit-function-declaration
to fontconfig to avoid these issues in the future. However, this
flag didn't compile on linux so I've left it as Windows only for now.
I also needed to add the LIBXML_STATIC define because not defining it
causes some functions on windows to be declared with
`__declspec(dllimport)` which results in linker errors since we are
actually statically linking libxml2.
