Bug#1123509: xterm: various issues with the U+FE0F VARIATION SELECTOR-16 (VS16) character after emoji
On 2025-12-17 19:56:40 -0500, Thomas Dickey wrote:
> On Wed, Dec 17, 2025 at 12:22:21PM +0100, Vincent Lefevre wrote:
> > But if xterm's Emoji width feature is enable, I don't see how this
> > can be fixable with wcwidth() since the width is contextual. It is
Well, in such a case, wcwidth() should return -1 on U+FE0F, not 0,
and everything should be fine: so software that relies on properties
like the width should not output this character to a terminal unless
it knows how it will be handled.
I've reported
https://sourceware.org/bugzilla/show_bug.cgi?id=33741
for glibc.
> well, yes - I view the spec as flawed because it changes things after
> they are processed. But it's not going away, it appears, so I decided
> to work through the implementation and resolve issues.
I don't see the word "terminal" in TR51
https://unicode.org/reports/tr51/
so that I would say that this is out of scope of this TR, which is
how text should be interpreted, not how it will be transferred in
specific cases. Said otherwise, outputting VS15/VS16 to a terminal
could be regarded as unspecified behavior and thus should be avoided
(but in such a case, wcwidth should return -1). In practice, ignore
VS15 and VS16 by default.
IMHO, to support TR51, software that sends data to a text terminal
should transform emoji sequences to what the terminal can expect
and can handle with major drawbacks: think of wrapping, which could
be modified by such a variation selector because the change of the
width occurs after the initial character is output. It seems that
TR51 assumes that the full strings are known in advance, which is
not the case with a text terminal, hence the need for a different
handling.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Reply to: