Re: Variant wcwidth results on Solaris

[Gavin Smith]

Thank you for your detailed response.

> 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.

> > Would it be possible for gnulib to override the system wcwidth if it has
> > unusual return values?
> 
> When you use a gnulib module that overrides a system function, you
> can influence its behaviour by setting the cache variable before gl_INIT.
> In this case, if you set
>   gl_cv_func_wcwidth_works=no
> you will get the gnulib override on all platforms.
> 
> Or you can modify the test program locally, for your package. [2]

This may be the best approach.

> > wcwidth is used by the texi2any program in Texinfo to output to 
> > monospaced plain text for use in a terminal emulator.  It is used for 
> > wrapping lines.
> 
> Ah, but wcwidth is a poor algorithm for line-breaking. The modern
> algorithms are specified in Unicode, and you have an implementation
> of the essential part of this algorithm in gnulib and in libunistring.

The way that texi2any does it is probably wrong for some languages.
Using the proper algorithms would be a larger change, so at the moment I 
just want to fix the line length issue.

> 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?

I looked through the files in the gnulib repository and eventually found 
the lib/unilbrk.in.h file documenting the functions that are provided.  
It says in it "assuming the uc_width" function.  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.

I don't see any reason why uc_width from gnulib/libunistring should be 
consistent across platforms and the results from the wcwidth function 
when the wcwidth module is in use should not be.  If the system wcwidth 
was worth respecting shouldn't uc_width use its values?

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.

> Another approach is to not include the code from gnulib, but instead
> rely on a preinstalled GNU libunistring. For this, use the gnulib
> module 'libunistring'.

libunistring looks like a very useful library, and I was not aware of 
it.  There is no reference to this library in the gnulib manual or the 
glibc manual.  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?