Fixes#359
See #359 for a test script. The unit tests were also wrong. I used the
test script in #359 to verify the exact column that tabstops should be
set at.
Fixes#143
There were multiple issues with the previous calculation. First, we
expected dash width COULD be negative and protected against it, but our
dash width calculation type was unsigned! With the proper font metrics,
this led to an underflow safey panic.
Second, as part of the dash width calculation, we are tryign to downstep
the size of the gaps so we can try to fit dashes within a cell. But we
were not using those adjusted gap sizes. With the proper font metrics,
this could lead to an assertion failure seen in #143.
This fixes the calculations. They produce the same numbers, but do so in
a more Zig-idiomatic way while fixing the above two issues.
WezTerm claims this is an emerging de-facto standard for terminal emulator identification:
a103b6d97a/config/src/config.rs (L1526-L1529)
One example of usage in the wild is neovim doing capability detection:
f050aaabbb/src/nvim/tui/tui.c (L206-L211)
Ghostty now reports this:
$echo $TERM_PROGRAM
ghostty
$echo $TERM_PROGRAM_VERSION
0.1.0-main+aa08f3c
I think it's really nice that the commit hash is included, as users can provide this in issue reports. WezTerm does the same.
I use these variables in my tui library in addition to $TERM and $COLORTERM for capability detection, which is what motivated this PR.
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>
