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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 26 Jun 2025 11:35:37 +0100
> Cc: tromey@adacore.com, aburgess@redhat.com, gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> As the blog explains, 
> 
>  "historically terminals used wcwidth, shells, editors, and other TUI apps also use wcwidth, and continue
>   to do so today. Even though it produces the wrong values for multi-codepoint graphemes, at least the
>   wrong values are often consistently wrong across terminal emulators."
> 
> So what can go wrong is grapheme clustering.  Both the terminal and the app must agree on
> clustering for that to work properly.  We could implement that protocol in GDB today, as there's
> a way to query if the terminal supports it.  But I'm not proposing that.
> 
> So if we ignore multi-codepoint graphemes, then wcwidth always matches what the
> terminals do.

Using wcwidth should probably work in many cases, but we still assume
that the terminal uses a font whose glyphs' width agrees with wcwidth.
That is not a given.

> > 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.
> 
> Note that for the use case we're talking about, the character used as current-line indicator,
> it's always going to be " <marker> ", with spaces or tabs or endline surrounding it,
> there is no risk of the character we choose bumping into other characters we don't control
> and forming a cluster sequence.  If <marker> itself is not a cluster, and is a single
> (maybe wide) character, then wcwidth returns the right thing.

Don't we allow the users to specify their own characters or strings
for this?  If not, all we have to do is verify that the characters we
pick for these purposes don't have the problems and always (or at
least in most cases) agree with wcwidth.

> For the wcwidth returns -1 scenario, I see two choices: 
> 
>  - assume width of one cell, and print marker from style anyhow, or,
> 
>  - fallback to hardcoded "*" character, like today's output.

This is a subset of a more general issue with wcwidth: it cannot be
relied upon to know about arbitrary characters, unless the locale's
codeset is UTF-8.  Because usually wcwidth only knows about characters
supported by the locale's codeset.

The best solution to overcome this is to have our own database of
character-width values.  (We actually only need the characters whose
width is different from 1, i.e. zero-width and double-width
characters.)  That's what Emacs does.  The downside is that we'd need
to maintain this database as characters are added to Unicode (we could
have a script that generates the database automatically from a
relevant Unicode data file).

Another alternative is to allow the definition of the width as part of
defining the character(s) used for each indicator.  Then we won't need
wcwidth/wcswidth at all.