Add pretty printing to the +list-keybinds command. This is done by
bringing in a dependency on libvaxis to handle the styling. Pretty
printing happens automatically when printing to a tty, and can be
disabled either by redirecting output or using the flag `--plain`
Related to #1802
CSIu format sends a unicode codepoint but we were just sending the first
byte of the utf8 sequence, which is very much not right. This fixes that
by parsing the utf-8.
It isn't defined what to do if the utf-8 sequence is invalid or has
multiple codepoints so we just skip CSIu encoding in that case.
Reproduction: HU layout Ctrl+ő
On release, we were previously not sending an alt text (we were sending
it properly on press). Kitty sends it also on release and the spec makes
it clear we should send it on release. This was just due to some faulty
logic; added a test and fixed that.
Fixes#1802
This allows `keybind` configurations to map to any Unicode codepoint. This enables keybindings for which we don't have a registered keycode or for custom keyboard firmwares that may produce arbitrary text (but the Ghostty support is limited to a single codepoint).
The `keybind` syntax is unchanged. If a bound character doesn't map to a known logical key that Ghostty knows about, we map it to a Unicode codepoint. The unicode codepoint is compared against the _unshifted codepoint_ from the apprt key event.
Note that this binding is to a single _codepoint_. We don't support arbitrary sequences of characters or multi-code point graphemes for keybindings due to the complexity in memory management that would introduce.
This also provides a good fallback for scenarios where it might make sense to educate Ghostty about a key code or fix a bug in our keyboard input system, but the unicode data is correct. In that scenario, unicode key binds should allow key binds to still work while we investigate the input issues.
Example:
```
shift+ö=text:hello
```
This now works as expected on a US hardware keyboard with the Hungarian keyboard layout.
Allows for high dpi displays to get odd numbered pixel sizes, for
example, 13.5pt @ 2px/pt for 27px font. This implementation performs
all the sizing calculations with f32, rounding to the nearest pixel
size when it comes to rendering. In the future this can be enhanced
by adding fractional scaling to support fractional pixel sizes.
In korean input method on macos, it should simply return empty string.
Issue was created after https://github.com/mitchellh/ghostty/pull/1659.
```
gksr<BS> # 한ㄱ<BS>
```
'ㄱ' at the end should be removed with single <BS>, but for now
it requires two <bs> to remove 'ㄱ'.
Fixes#1618
Font sizes in configuration were always a u8, but the keybinding and
internal state was a u16 so it allowed for an ever-growing font size. At
a certain point, there is an integer overflow which causes it to wrap
around. This is all silly, 255 should be large enough for anyone[1]
[1]: Ready to be super wrong about this
Ghostty does not report associated text on macOS when
macos-option-as-alt is enabled for _any_ key press, whether or not the
Alt modifier is actually present. The "option as alt" decision should
only be made when the alt modifier is present.
This follows a specific behavior Kitty has, but no other terminal seems
to have, but it is a reasonable behavior that is in use by real programs
as found by our beta testing community.
We diverge from Kitty though in that we only apply this to ASCII
letters. Kitty does not CSIu encode special characters like `@` or `$`.
For these characters, Ghostty still encodes it as specified by fixterms.
Related to #1507
The comments in this change have most of the detail. The primary gist:
- caps-lock is handled correctly so #1501 is still fixed
- only characters pressed with the shift key are affected
Fixes#1505
I verified this behavior with every other terminal and I've added test
cases for it. We previously had a test case to assert the opposite,
which is incorrect.
