bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Variant wcwidth results on Solaris


From: Bruno Haible
Subject: Re: Variant wcwidth results on Solaris
Date: Sat, 30 Mar 2019 12:33:32 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; )

Hi Gavin,

> > Different systems have different terminal emulators, and accordingly 
> > also different wcwidth functions.
> 
> Without knowing anything about the terminal emulators in question, it 
> seems to me likely that there would be several terminal emulators with 
> different behaviour on the same system, all using the same libc.

Yes, this can happen as well, and if this happens, the fact that there
are wcwidth implementations hardwired in libc and even in the Linux kernel
surely produces glitches.

> > In gnulib it is in the modules
> >   unilbrk/ulc-width-linebreaks
> >   unilbrk/u8-width-linebreaks
> >   unilbrk/u16-width-linebreaks
> >   unilbrk/u32-width-linebreaks
> > Pick the one that fits your needs.
> 
> I don't know how anybody is supposed to find out about these modules.
> They are not documented anywhere in gnulib.texi.  Is one just supposed 
> to look through the files under lib/ and modules/ in the gnulib 
> repository?

They are listed in https://www.gnu.org/software/gnulib/MODULES.html,
although that does not really count as documentation. The main documentation
is in the GNU libunistring manual [1].

> This seems to perform 
> the same function as wcwidth.  If we could replace wcwidth with uc_width 
> and uc_width from gnulib (or the same function from libunistring) and 
> that was consistent across platforms, then the issue would be solved.

Unfortunately, this is not possible, because wcwidth takes a wchar_t
(wide character) argument, which is not the same as a Unicode character.[2]

> It appears that lib/wcwidth.c does actually use uc_width.  So the best 
> solution might be to carry on using the wcwidth function in the source 
> code for texi2any (instead of changing this to uc_width), and change the 
> configure-time checks to make sure that the replacement function is used 
> when the values from the system wcwidth are unusual.

This is one way to solve your immediate problem, yes.

> Should a note be added to 
> doc/posix-functions/wcwidth.texi saying that libunistring should be used 
> if you want to get consistent results across systems?

wcwidth is a POSIX function. The idea of wanting to get the same result
across platforms, for a POSIX function, is a too strong wish. POSIX allows
different implementations. Gnulib does overrides only when
  - the platform's implementation is clearly buggy, or
  - the glibc implementation is vastly superior in all aspects, or
  - the differences between platforms are unacceptable.

Bruno

[1] 
https://www.gnu.org/software/libunistring/manual/html_node/unilbrk_002eh.html
[2] 
https://www.gnu.org/software/libunistring/manual/html_node/The-wchar_005ft-mess.html




reply via email to

[Prev in Thread] Current Thread [Next in Thread]