This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #8 from Thorsten Glaser <tg at mirbsd dot de> ---
Hi Egmont,

only a short response because we have FrOSCon/FrogLabs preparations and
workshop until Monday:

We’re not strictly speaking deviating from UCD because UCD does *not* define
wcwidth.

Terminal emulators use wcwidth, especially xterm uses ONLY it *and* defines it.

Applications such as editors in the terminal (cf. jupp) use wcwidth or carry
their own data which is prepared the same way as wcwidth (often they use a copy
of xterm's code).

You speak of compatibility and breaking. Strictly speaking, the switch glibc
recently (two or three majors, I think) did to regenerated data *did* break
applications, and this bugreport is 100% returning the glibc data to the way it
was before in the places the previous change introduced bugs, while still
keeping it up-to-date with recent Unicode.

So, therefore, with this patch applied, less things will break than without.

Outlyers like libglib (used by only one of the multitude of terminal emulators)
can then import the data (and mechanism used to generate) from here.

Other systems use the old wcwidth code from xterm, to which this one (with my
patches applied) is compatible for all chars that did not get changed in or
added to Unicode, which is the maximum compatibility and an easily to achieved,
and achievable and should-be-achieved goal.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]