This is the mail archive of the cygwin mailing list for the Cygwin 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]

wcwidth and terminals [Re: Mg3a - a version of Mg2a developed on Cygwin]

Am 24.02.2011 09:56, schrieb Corinna Vinschen:
When on Cygwin, you might better use Cygwin's(*) wcwidth function.  It's
based on the same code from Markus Kuhn, but it interacts with the
setlocale function to make sure that the width returned for the CJK
ambiguous width characters makes sense in the given locale.  Plus, it
supports a Cygwin-specific locale modifier '@cjknarrow' which allows the
user to modify this behaviour.  When using your own wcwidth, you're
giving up on this feature.
On the other hand, not specific for cygwin, the wcwidth/wcswidht functions are in general based on installed locale data.
But you can never know whether the terminal you are running in actually uses those data.
On a Linux system, you may encounter a wide range of different environments, for example:
rxvt based on system locale which is often based on an outdated locale data installation (e.g. Unicode 3)
xterm with a hard-coded wcwidth
mlterm with some tweaks
remote operation (rlogin/ssh to/from other system) with inconsistent locale data base

For that reason, my editor mined implements an auto-detection of actual terminal width data (checking Unicode version and a number of terminal-specific odds).

For cygwin, it might be useful (although not standard) for wcwidth to consider whether it's running in a cygwin console or a terminal, so e.g. wcwidth (0x8080) should return 2 in mintty but 1 in a cygwin console.

Erik Blake wrote:
And if you don't mind [L]GPL licensing, gnulib provides a source code
replacement that guarantees wide character support on all modern porting
platforms (particularly useful for mingw, which is sorely lacking on
this front); and is currently working on introducing a wwchar_t type
that is guaranteed to be UTF-32 even on cygwin (this is how coreutils
gets wide character support for things like wc).  Portions of that
gnulib code are incorporated into libunistring.  But from the sounds of
your program's license, I'm not sure you can take advantage of gnulib or
Maybe I should check whether my auto-detection code could be contributed to that project...


Problem reports:
Unsubscribe info:

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