Problem: Some characters get a different width in a terminal window
than in an ordinary window.
Solution: When the application provides a width function, use it as the
only source for the width of a character.
libvterm looks up its own "fullwidth" table before calling the wcwidth() function that Vim provides. That table is from Unicode 9, while Vim follows a newer version, so U+1F93B and U+1F946 are two cells wide in a terminal window and one cell wide everywhere else. The tables also disagree about U+302A-302D and U+3099-309A, which are combining characters that the table reports as two cells wide.
Skipping the table when a wcwidth() function is provided makes that function the only authority, so a terminal cell gets the same width as the character gets in a buffer. A build of libvterm without such a function keeps using the table.
https://github.com/vim/vim/pull/21213
(2 files)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@leonerd Heads-up in case this is useful upstream: src/fullwidth.inc is
stale. Re-running find-wide-chars.pl under Perl 5.38 (Unicode 15.0) splits
{ 0x1f90d, 0x1f971 } into three ranges, because U+1F93B and U+1F946 carry
East_Asian_Width=Neutral in current Unicode data while the committed table
still reports them as two cells wide. Separately, the table covers
U+302A-302D and U+3099-309A, which are Mn, so vterm_unicode_width() returns
2 for them before mk_wcwidth() gets to its combining check.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()