When font shaping grapheme clusters, we erroneously used the font index
of a font that only matches the first codepoint in the cell. This led to the
combining characters being [usually] unknown and rendering as boxes.
For a grapheme, we must find a font face that has a glyph for _all codepoints_
in the grapheme.
This also fixes an issue where we now properly render the unicode replacement
character if we can't find a font satisfying a codepoint.
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).
We previously never set the focused pointer to null. I thought this
would be fine because a `hasSurface` check would say it doesn't exist.
But I didn't account for the fact that a deleted surface followed very
quickly by a new surface would free the pointer, then the allocation
would reuse the very same pointer, making `hasSurface` return a false
positive.
Well, technically, hasSurface is not wrong, the surface exists, but its
not really the same surface, its just a surface that happens to have the
same pointer as a previously freed surface.
Co-authored-by: Will Pragnell <wpragnell@gmail.com>
* font: disable default font features for Menlo and Monaco
Both of these fonts have a default ligature on "fi" which makes terminal
rendering super ugly. The easiest thing to do is special-case these
fonts and disable ligatures. It appears other terminals do the same
thing.
macOS translates inputs such as shift+tab into the control character tab
(ascii 0x09). Linux/GTK does not translate character inputs except to
printable characters. We don't want control character translations
because these are all handled manually by our key encoder (i.e.
translating ctrl+c to 0x03).
U+226A is 1-char wide according to the Unicode database but renders very
wide in many fonts. This causes it to leak outside of its grid cell. We
should scale down by x the same way we scale down by y.
