[Fwd: [1.7] wcwidth failing configure tests]

IWAMURO Motonori deenheart@gmail.com
Sat Jun 6 12:22:00 GMT 2009


# Continuation of discussion.
#
# I hope that all the applications work correctly only by setting
"LANG=ja_JP.UTF-8".
# I don't hope that I give up the use of the binary packages and that
I keep applying many local patches.


> I don't think that it is the good idea because:
>
> - It is "a cygwin-specific solution (or workaround)".
> - In NetBSD, the change to which wcwidth of East Asian Ambiguous Characters returns 2 by CJK locale is planned.

- and, I don't think that I need make special cases give priority more
than general cases.

>> - I heard that there is an existing implementation that behave like my
>> proposal. (Sorry, I didn't hear the system name.)
> Even if so, I think the way I described is more compatible with the locale
> mechanism as used elsewhere.

I think that ALL locale implementations should treat East Asian
Ambiguous Character Width as 2 for CJK locale.

>> It is no problem because we -- most Japanese language users -- need
>> not change the settings of mintty and locale after first setup.
>> We set LANG=ja_JP.UTF-8 and select a Japanese font for mintty.
> In any case, mined running in mintty will detect CJK width itself,
> regardless of locale setting, with coming versions of both programs
> even when it gets changed on-the-fly :)

Sorry, I can't understand above because I am not good at English.

> This sounds complicated.

I don't think so. I think that we should consider the following issues
if a new mechanism is introduced.

The existing locale / terminal API don't support:
- Unicode BiDi.
- Unicode control characters.
- Unicode combining characters.
- Multilingualization. (*)
- Detect font/fontset information selected with terminal emulator.
(including, need to consider the case of no-tty)

* Now, we can't use Japanese, Chinese, and Korean at the same time
even if we use Unicode.
  Because many font glyphs are quite different even if the code point
is the same in each language.

> With my proposal, an application that wishes to auto-adjust on width
> properties (maybe even when changing) and which (unlike mined) uses
> the system wcwidth functions could proceed as follows:
> * Detect CJK width by using a simple test string width detection.
> * (Optional) When receiving a SIGWINCH signal (future version of MinTTY),
>  repeat this detection.
> * If e.g. LC_CTYPE starts with "ja_JP.UTF-8", call setlocale with
>  either "ja_JP.UTF-8@cjkwidth" or "ja_JP.UTF-8".

How to detect it? The application using wcwidth is not necessarily
executed with terminal emulator. (e.g. text formatter)

>> > I'm not happy with the idea of a cygwin-specific solution (or workaround).
>> I think that it is not cygwin-specific solution.
> As I tried to suggest above, using "UTF-8" for different width data on one
> system would be quite specific, using the "@" modifier syntax would not.

"UTF-8" is only an encoding scheme. It does not specify the character width.
-- 
IWAMURO Motnori <http://vmi.jp/>

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list