Alexander V. Lukyanov wrote:
> Well, Solaris wcwidth has many other deficiencies, e.g:
> solaris_wcwidth(0x220)=-1
Was added in Unicode 3.2.0 (2002).
> solaris_wcwidth(0x221)=-1 mk_wcwidth(0x221)=1
> solaris_wcwidth(0x234)=-1 mk_wcwidth(0x234)=1
> solaris_wcwidth(0x235)=-1 mk_wcwidth(0x235)
On Tue, Aug 26, 2008 at 09:32:32AM +0200, Bruno Haible wrote:
> 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 designa
On Tue, Aug 26, 2008 at 09:32:32AM +0200, Bruno Haible wrote:
> Alexander V. Lukyanov wrote:
> > Let's measure it.
> >
> > $ time ./wcwidth-solaris
> > wcwidth(0x2022)=2
> >
> > real0m2.205s
> > user0m2.200s
> > sys 0m0.000s
> >
> > $ time ./wcwidth-rpl
> > wcwidth(0x2022)=1
> >
>
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 wcwi
On Sun, Aug 24, 2008 at 12:29:06PM +0200, Bruno Haible wrote:
> > +dnl On Solaris 8, wcwidth(0x2022) (BULLET) returns -1.
>
> This is not the case for me:
I'm sorry. In my case it also gives 2, not -1. (I forgot to call setlocale
in the new test program, oops). New patch attached.
> Which lo
Hi,
Alexander V. Lukyanov wrote:
> I'm trying to use wcwith replacement on Solaris 8 and have noticed some
> problems. At first, the test for replacement did not detect the problem and
> thus did not replace the system function (patch for this is attached).
The comment in your diff says:
> +
