Re: [PATCH 2/2] Allow check-mark to be changed for CLI

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 25 Jun 2025 20:11:07 +0100
> Cc: aburgess@redhat.com, gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> >> I don't think there's any way to figure out what the display width of a
> >> string might be.  At least, not unless gdb adds a dependency on
> >> something like libicu.
> > 
> > I don't think even libicu will be enough, because the terminal
> > emulators vary in this respect.
> > 
> > There's some recent protocol to help with this, but I don't think it's
> > supported widely enough for GDB to rely on it.
> 
> I'm curious on what protocol is this, and what it addresses.

That's "Mode 2027".  For the details, see

     https://github.com/contour-terminal/terminal-unicode-core
and
     https://mitchellh.com/writing/grapheme-clusters-in-terminals

> If we assume monospace font in the terminal, what goes wrong?

Monospace font is only relevant for single-character strings.  Once
you try to display a string that has more than one Unicode character,
a terminal may or may not combine those characters into one or more
font glyphs (it's a many-to-many relation, so you could have M
characters displayed as N glyphs, where M could be lass than, equal,
or greater than N, depending on the characters in the string and the
capabilities of the font used by the terminal).  If that happens,
wcswidth will usually produce an incorrect result, because it doesn't
(and cannot) know about these features of the terminal, and basically
just sums the results of wcwidth of each character in the string.

> Is there a downside to using the number of columns wcwidth says the character occupies,
> and default to 1 if wcwidth returns -1?

See above.  This discussion started in the context of showing Emoji,
where the case of combining several characters into one or more glyphs
happens very frequently.  For example, the sequence U+2713 followed by
U+FE0F VARIATION SELECTOR-16 should display a single glyph on capable
terminals (try it in a GUI session in Emacs to see that), although
it's two characters.  In some cases, wcswidth will do the job, because
control characters like U+FE0F have zero width in its database, but
that is not universally so.  For example, the following string of
characters:

  U+1F468 U+200D U+1F469 U+200D U+1F466

will be displayed by capable terminals as a single glyph (again, try
in Emacs to see), but wcswidth will probably return 6 for it.

And even for single-character strings wcwidth will sometimes produce
incorrect results, because the fonts used by modern terminal emulators
for some exotic characters (like Emoji) are not monospaced.