Re: [PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

Hi. 2009/6/27 Andy Koppe : > And then there's the Linux compatibility angle, where ja_JP.UTF-8 > means ambiguous width 1 not 2. I want you not to judge it based on the behavior of current Linux. Because: - I don't think the behavior is correct. - Now, I am creating the patch for the problem. --

Re: [PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

2009/6/15 Corinna Vinschen: >> > Define the default for ja, ko, and zh to use width = 2, with a >> > @cjknarrow (or whatever) modifier to use width = 1. >> >> I think it is good idea. > > If everybody agrees to this suggestion, here's the patch.  Tested > with various combinations like > >  lang=ja

Re: [PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

On Jun 19 13:02, Thomas Wolff wrote: > I wrote: > > Despite IWAMURO Motonori's withdrawal, I think symmetry would be the > > right approach to take. The major aspect is how to reflect the actual > > behaviour of existing terminal environments. ... > > > ... > > The "locale interface" (syntax and

Re: [PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

I wrote: > Despite IWAMURO Motonori's withdrawal, I think symmetry would be the > right approach to take. The major aspect is how to reflect the actual > behaviour of existing terminal environments. ... > ... > The "locale interface" (syntax and semantics of LC_* strings) is defined > in a modu

Re: [PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

2009/6/18 Thomas.Wolff: > And as a matter of fact, > you can run both xterm and MinTTY with a non-CJK locale and ambiguous > characters being wide. This is achieved by invoking xterm -cjk_width or > by selecting an according font in MinTTY, e.g. Ming, SimSun, MS Mincho, > or even just the popular L

Re: [PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

On Jun 18 14:09, thomas.wo...@nsn.com wrote: > 2009/6/16 Corinna Vinschen > > However, besides of being unnecessary, other systems like Linux or BSD > > use the language string as directory name relative to the > > /usr/share/locale directory. ?If this gets ever used on non-Cygwin > > systems, the

Re: [PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

2009/6/16 Corinna Vinschen : > On Jun 15 23:35, IWAMURO Motonori wrote: >> 2009/6/15 Corinna Vinschen: >> > If everybody agrees to this suggestion, here's the patch. >> >> Is the name of modifier prefix "cjk-" good? It influences not CJK >> characters but a part of symbols and European characters.

Re: [PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

OK. I withdraw my proposal. 2009/6/16 Corinna Vinschen : > On Jun 15 23:35, IWAMURO Motonori wrote: >> 2009/6/15 Corinna Vinschen: >> > If everybody agrees to this suggestion, here's the patch. >> >> Is the name of modifier prefix "cjk-" good? It influences not CJK >> characters but a part of symb

Re: [PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

On Jun 15 23:35, IWAMURO Motonori wrote: > 2009/6/15 Corinna Vinschen: > > If everybody agrees to this suggestion, here's the patch. > > Is the name of modifier prefix "cjk-" good? It influences not CJK > characters but a part of symbols and European characters. > Please refer to Andy's opinion: >

Re: [PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

2009/6/15 Corinna Vinschen : >> Yes, but the guideline exists. >> http://cygwin.com/ml/cygwin/2009-05/msg00444.html > > A single mail in a single mailing list of a single project.  That's rather > a suggestion than a guideline... Sorry, my writing was bad. My quotation is a part of Unicode Standar

[PATCH] Add "@cjknarrow" modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])

On Jun 14 22:18, IWAMURO Motonori wrote: > 2009/6/13 Corinna Vinschen > > The problem appears to be that there is no standard for the handling > > of ambiguous characters. > > Yes, but the guideline exists. > http://cygwin.com/ml/cygwin/2009-05/msg00444.html A single mail in a single mailing lis

Re: [Fwd: [1.7] wcwidth failing configure tests]

2009/6/13 Corinna Vinschen : >> I'm not sure which "standard" you are referring to. > > The problem appears to be that there is no standard for the handling > of ambiguous characters. Yes, but the guideline exists. http://cygwin.com/ml/cygwin/2009-05/msg00444.html > 2) Unicode Standard Annex #11 >

Re: [Fwd: [1.7] wcwidth failing configure tests]

2009/6/13 Thomas Wolff : > I have checked source data files in /usr/share/i18n/charmaps on my Linux > system, e.g. "UTF-8.gz". > character widths are the same for all locales with the same "charmap". It was reported as a bug, but it isn't fixed now...X-( http://sourceware.org/bugzilla/show_bug.

Re: [Fwd: [1.7] wcwidth failing configure tests]

On Jun 12 17:38, Thomas Wolff wrote: > IWAMURO Motonori wrote to me by private mail: > > I oppose your proposal because I think that it is useless for us. > > > > 2009/6/6 Thomas Wolff : > >> the intention is that the "codepage" information should be the same > >> for all locales having thbe "UTF-

Re: [Fwd: [1.7] wcwidth failing configure tests]

IWAMURO Motonori wrote to me by private mail: > I oppose your proposal because I think that it is useless for us. > > 2009/6/6 Thomas Wolff : >> the intention is that the "codepage" information should be the same >> for all locales having thbe "UTF-8" (or any other) charmap. So you >> cannot free

Re: [Fwd: [1.7] wcwidth failing configure tests]

2009/6/6 Corinna Vinschen : > I vote for @cjkwide, regardless of Andy's objection.  People using CJK > will know the meaning and it has the additional advantage to be a rather > simple to memorize identifier. I oppose @cjkwide approach because I don't think that I need make special cases give prio

Re: [Fwd: [1.7] wcwidth failing configure tests]

2009/6/6 Andy Koppe : > However, to make the locale setting more convenient for CJK users, > there could be modifiers for both widths. Without modifier, the CJK > locales would default to "Ambiguous Wide", while everything else would > default to "Ambiguous Narrow". It is acceptable for me. > Puz

Re: [Fwd: [1.7] wcwidth failing configure tests]

# 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-s

Re: [Fwd: [1.7] wcwidth failing configure tests]

> > Thomas, couldn't you have discussed this in the two weeks I was on > vacation?  Why did you wait until I implemented the language-based > approach? > Sorry, that's largely my fault. Among a bunch of other MinTTY issues we were privately discussing various more or less mad schemes to communic

Re: [Fwd: [1.7] wcwidth failing configure tests]

I oppose your proposal because I think that it is useless for us. 2009/6/6 Thomas Wolff : > the intention is that the "codepage" information should be the same > for all locales having thbe "UTF-8" (or any other) charmap. So you > cannot freely change width information among locales with the same

Re: [Fwd: [1.7] wcwidth failing configure tests]

On Jun 5 18:25, Thomas Wolff wrote: > IWAMURO Motonori wrote: > > 2009/5/21 Thomas Wolff : > > >> > Therefore, I propose to use *_cjk() when the language part of LC_CTYPE > > >> > is 'ja', 'ko', 'vi' or 'zh'. > > > The problem with this is > > > 1. As you say, there is no standard. > > > But, > >

Re: [Fwd: [1.7] wcwidth failing configure tests]

2009/6/5 Thomas Wolff: > the locale syntax allows for an optional "modifier" which can be used to > specify deviations, e.g. >        de_DE           has charmap ISO-8859-1 >        de...@euro      has charmap ISO-8859-15 >        uz_UZ           has charmap ISO-8859-1 >        uz...@cyrillic  has

Re: [Fwd: [1.7] wcwidth failing configure tests]

IWAMURO Motonori wrote: > 2009/5/21 Thomas Wolff : > >> > Therefore, I propose to use *_cjk() when the language part of LC_CTYPE > >> > is 'ja', 'ko', 'vi' or 'zh'. > > The problem with this is > > 1. As you say, there is no standard. > But, > - I think that my proposal doesn't violate any specifi

Re: [Fwd: [1.7] wcwidth failing configure tests]

I correct my proposal. 2009/5/15 IWAMURO Motonori : > I propose to use *_cjk() when the language part of LC_CTYPE > is 'ja', 'ko', 'vi' or 'zh'. LC_CTYPE is 'ja', 'ko', or 'zh'. I remove 'vi'. (advice from a NetBSD locale part maintainer) -- IWAMURO Motnori -- Unsubscribe info:

Re: [Fwd: [1.7] wcwidth failing configure tests]

2009/5/21 Thomas Wolff : >> > Therefore, I propose to use *_cjk() when the language part of LC_CTYPE >> > is 'ja', 'ko', 'vi' or 'zh'. > The problem with this is > 1. As you say, there is no standard. But, - I think that my proposal doesn't violate any specification. - I heard that there is an exi

Re: [Fwd: [1.7] wcwidth failing configure tests]

Corinna Vinschen wrote: > On May 12 17:56, Andy Koppe wrote: > > > And here's another question. ?The utf8*.h files claim they have been > > > generated from the unicode.txt file of the Unicode 3.2 standard. ?Do we > > > have the script which generated the utf8*.h files? ?Can we regenerate > > > th

Re: [Fwd: [1.7] wcwidth failing configure tests]

On May 14 17:51, Jeff Johnston wrote: > Corinna, I have no problem with checking the new patch in and extending > this later, assuming you have thoroughly tested this implementation. I tested it with _MB_CAPABLE defined and with _MB_CAPABLE undefined. Both variations worked as expected, the latt

Re: [Fwd: [1.7] wcwidth failing configure tests]

Corinna Vinschen wrote: On May 15 00:58, IWAMURO Motonori wrote: 2009/5/13 Corinna Vinschen : http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c This looks nice. Do you import Markus Kuhn's wcwidth implementation? Trouble is, there's the thorny issue of the "CJK Ambig

Re: [Fwd: [1.7] wcwidth failing configure tests]

On May 15 00:58, IWAMURO Motonori wrote: > 2009/5/13 Corinna Vinschen : > >> http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c > > > > This looks nice. > > Do you import Markus Kuhn's wcwidth implementation? > > >> Trouble is, there's the thorny issue of the "CJK Ambiguous Width" > >> category of char

Re: [Fwd: [1.7] wcwidth failing configure tests]

2009/5/13 Corinna Vinschen : >> http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c > > This looks nice. Do you import Markus Kuhn's wcwidth implementation? >> Trouble is, there's the thorny issue of the "CJK Ambiguous Width" >> category of characters, which consists of things like Greek and >> Cyrillic

Re: [Fwd: [1.7] wcwidth failing configure tests]

> How should that work?  The first half of the surrogate pair has not > enough information to decide that.  For instance, take the ranges > 0x10A01, 0x10A03 }, { 0x10A05, 0x10A06 }.  The information about the low > 10 bits of the Unicode value is in the second half of the pair.  From > the first ha

Re: [Fwd: [1.7] wcwidth failing configure tests]

On May 13 20:04, Andy Koppe wrote: > 2009/5/12 Corinna Vinschen: > >> Trouble is, there's the thorny issue of the "CJK Ambiguous Width" > >> category of characters, which consists of things like Greek and > >> Cyrillic letters as well as line drawing symbols. Those have a width > >> of 1 in Western

Re: [Fwd: [1.7] wcwidth failing configure tests]

2009/5/12 Corinna Vinschen: >> Trouble is, there's the thorny issue of the "CJK Ambiguous Width" >> category of characters, which consists of things like Greek and >> Cyrillic letters as well as line drawing symbols. Those have a width >> of 1 in Western use, yet with CJK fonts they have a width of

Re: [Fwd: [1.7] wcwidth failing configure tests]

On May 12 17:56, Andy Koppe wrote: > > And here's another question.  The utf8*.h files claim they have been > > generated from the unicode.txt file of the Unicode 3.2 standard.  Do we > > have the script which generated the utf8*.h files?  Can we regenerate > > the files to match the current Unicod

Re: [Fwd: [1.7] wcwidth failing configure tests]

> And here's another question.  The utf8*.h files claim they have been > generated from the unicode.txt file of the Unicode 3.2 standard.  Do we > have the script which generated the utf8*.h files?  Can we regenerate > the files to match the current Unicode 5.1 standard? There's Markus Kuhn's wcwi

[Fwd: [1.7] wcwidth failing configure tests]

Forwarded to newlib. - Forwarded message from Eric Blake - > Date: Tue, 12 May 2009 16:02:04 + (UTC) > From: Eric Blake > Subject: [1.7] wcwidth failing configure tests > To: cygwin AT cygwin DOT com > > I noticed this failure in various configure scripts (findutils, coreutils, > ..