[vim/vim] libvterm: characters can get a different width in a terminal window (PR #21213)

4 views
Skip to first unread message

h_east

unread,
Sep 3, 2026, 12:35:53 PM (4 days ago) Sep 3
to vim/vim, Subscribed
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.


You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/21213

Commit Summary

  • b942318 libvterm: characters can get a different width in a terminal window

File Changes

(2 files)

Patch Links:


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.Message ID: <vim/vim/pull/21213@github.com>

h_east

unread,
Sep 3, 2026, 12:36:36 PM (4 days ago) Sep 3
to vim/vim, Subscribed
h-east left a comment (vim/vim#21213)

@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.Message ID: <vim/vim/pull/21213/c5528895238@github.com>

Reply all
Reply to author
Forward
0 new messages