[Bug localedata/21750] column width of characters incompatible with classical wcwidth

["egmont at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21750

Egmont Koblinger <egmont at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egmont at gmail dot com

--- Comment #7 from Egmont Koblinger <egmont at gmail dot com> ---
(In reply to Mike FABIAN from comment #5)

> [...] setting these to 2 seems to be
> much better for users of terminals and that is what wcwidth
> in glibc is mostly used for after all).

Guys,

With a huge thanks and great respect towards you working on addressing these
issues, allow me please firmly oppose against deviating from the Unicode
database.

The width is probably indeed primarly used by terminal emulators and apps
running inside. They, however, use all kinds of various sources for this data,
not just glibc's wcwidth().

For example, VTE-based emulators (such as GNOME Terminal) rely on glib's
g_unichar_iswide(), see [1]. Alas I don't have any usage metrics, but the poll
at [2] suggest that VTE's usage share amongst terminal emulators on Linux might
be somewhere in the ballpark of 50%.

As for apps, if my memories are correct, I believe Vim uses its own built-in
database rather than wcwidth(). So does the Joe text editor [3] (okay, it's a
really marginal one), and presumably many more apps.

Let alone all other non-glibc based systems with their own wcwidth()
implementation that one might ssh to/from.

For apps inside terminal emulators to work correctly, it's crucial that all the
relevant components agree on the width. This has caused quite a headache when
Unicode 9.0 changed the width of plenty of codepoints, see e.g. the bugreport
with animgif at [4] (and tons of duplicates in other bugzillas and
stackoverflow forums), but this is going to fade away as eventually everyone's
upgrading their Unicode version.

You cannot, however, reasonably assume that other folks out there, i.e.
terminal emulators as well as applications that don't rely on wcwidth() but
some other data source, or those other data sources such as glib and probably a
whole lot more, are all going to apply your modifications. And then again we
haven't talked about ssh'ing to/from non-glibc systems.

If a certain glyph does not fit in its designated character cell, most terminal
emulators will overflow it to the next cell. A slight overflow happens at way
more codepoints than the ones debated now, e.g. in case of VTE and a not too
large font, even the antialiasing of English letters such as 'W', 'm' overflows
to the next cell. Of course I understand that the overflow in case of U+3248
"㉈" and friends is way more prominent, potentially causing the given and the
subsequent glyph not to be readable at all, which is indeed bad.

But causing the entire canvas's contents to fall apart is even worse. And
that's what typically happens when players of the game disagree on the width,
as seen e.g. again at [4].

If you'd really like to see these particular codepoints becoming double wide
(which I'm also in favor of), I firmly believe this change should be made in
the Unicode database first, so that eventually everyone implementing a
wcwidth()-like method gets that update; rather than just glibc, resulting in a
long-term disagreement between parties and in turn inevitable corruption of the
entire terminal window in quite a few terminal emulators and apps.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=772890
[2] https://opensource.com/life/15/11/top-open-source-terminal-emulators
[3] https://sourceforge.net/p/joe-editor/bugs/363/
[4] https://github.com/powerline/powerline/issues/1652

-- 
You are receiving this mail because:
You are on the CC list for the bug.