The [fixterms](http://www.leonerd.org.uk/hacks/fixterms/) "Really
Special Keypresses" section suggests using CSI 1 ; Ps R for F3, but this
is also a valid cursor position report. The intention was to make
back-compatible changes, so this is fairly considered a specification
bug.
This changes F3 in legacy mode to send CSI 13 ; Ps ~ instead, this is a
variant listed in fixterms, is what kitty protocol uses, and lacks the
problematic overlap with cursor positions.
The KeyEncoder.zig unit test has been changed accordingly, and all tests
pass on my machine.
The [fixterms](http://www.leonerd.org.uk/hacks/fixterms/) "Really
Special Keypresses" section suggests using CSI 1 ; Ps R for F3, but this
is also a valid cursor position report. The intention was to make back-
compatible changes, so this is fairly considered a specification bug.
This changes F3 in legacy mode to send CSI 13 ; Ps ~ instead, this is a
variant listed in fixterms, is what kitty protocol uses, and lacks the
problematic overlap with cursor positions.
The KeyEncoder.zig unit test has been changed accordingly, and all tests
pass on my machine.
The comment in `function_keys.zig` was missing the `>` character for the
sequence. I've confirmed that this was just the comment, Ghostty treats
the original as an SGR sequence, which it is. Conversely, it does treat
`\x1b[>4:2m` as activating modifyOtherKeys.
Add additional keypad keys to the encoding scheme. This allows Ghostty
to report KP_HOME and it's relatives. We also always check for a keyval
first, so we can report KP_7, etc as opposed to ASCII '7'.
This matches Kitty behavior on both macOS and Linux. In certain keyboard
modes and Kitty keyboard modes, the behavior changes but those already
matched (tested).
