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 <[email protected]> - 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)
