Re: wcwidth replacement problems

[Bruno Haible]

Alexander V. Lukyanov wrote:
> > (Giving the BULLET a width of 2 is a bit strange, but not really wrong.)
> 
> Well, it does not seem to match current xterm behavior, and thus leads to
> strange visual results. I don't know, maybe it is an xterm problem, but the
> easiest way was to substitute wcwidth.

Probably the Solaris wcwidth is made to match some Japanese terminal
emulators, rather than xterm? In such terminal emulators, many characters
that have width 1 in xterm are represented with width 2.

U+2022 (BULLET) is designated as "ambiguous width" in Unicode 5.0.0
(ftp.unicode.org ArchiveVersions/5.0.0/ucd/extracted/DerivedEastAsianWidth.txt)
therefore I don't want to consider Solaris wrong here. You have to understand
that wcwidth is only an approximation because different terminal emulators
behave differently.

> > > BTW, why not use this one: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c ?
> > > It's public domain.
> > 
> > It has also its bugs [1]. Additionally, it's slower because it uses binary
> > search rather than immediate table accesses.
> 
> Let's measure it.
> 
> $ time ./wcwidth-solaris 
> wcwidth(0x2022)=2
> 
> real    0m2.205s
> user    0m2.200s
> sys     0m0.000s
> 
> $ time ./wcwidth-rpl 
> wcwidth(0x2022)=1
> 
> real    0m55.477s
> user    0m55.350s
> sys     0m0.000s
> 
> $ time ./wcwidth-mk 
> wcwidth(0x2022)=1
> 
> real    0m1.944s
> user    0m1.940s
> sys     0m0.010s

This is not a fair comparison: wcwidth-mk works only in UTF-8 locales,
whereas wcwidth() from the system and from gnulib return the right result
in all locales. The test whether the locale encoding is UTF-8 is precisely
what takes up most time in the gnulib replacement.

Bruno