On Feb 24 11:56, Bengt Larsson wrote: > Corinna Vinschen wrote: > >Just a hint: > > > >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. > > > >Better yet, convert wide chars to wide strings and use the wcswidth > >function. In contrast to wcwidth, it can also handle surrogate pairs. > > I don't use surrogates. I only use UTF-8 and UTF-32. But using cygwin's > wcwidth may be worth thinking about. I suppose it will be consistent > with mintty that way; otherwise not?
Yes, I think Andy uses the system functions as well. As for the wide char representation, wchar_t is UTF-16 on Cygwin, as on the underlying Windows, and surrogate pairs are always possible. You can't use any libc wide char function if you assume UTF-32. > Using wcswidth isn't very useful in the editor because it has special > requirements, like showing control characters with ^C. Well, it's not really such a big problem to special case wide char control values and just call wcswidth otherwise... > That's one of the > reasons I mostly wrote my own, all the special requirements. I always > iterate of bytes, which are converted in a mode-dependent way to ints > (UTF-32). Do you have a case-insensitive compare? Because I limited that > to ASCII. wcscasecmp and wcsncasecmp are both available. But obviously they use UTF-16, since wchar_t is UTF-16. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
