Mail Archives: cygwin/2009/06/18/08:10:25
2009/6/16 Corinna Vinschen <corinna-cygwin AT cygwin DOT com>:
> 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:
>> http://cygwin.com/ml/cygwin/2009-06/msg00240.html
>>
>> It personally proposes "ambinarrow" because the switch of Vim is "ambiwidth".
>
> I think "cjk" in the name is the right choice. ?There are no ambiguous
> characters in western languages (well, probably there are, but the
> ambiguity is not on the level of character widths). ?This is a problem
> which only has a meaning in these so called CJK languages. ?It makes
> sense to me to use this in the modifier name.
I agree with keeping "cjk" in the modifier name (also because the xterm
option is called -cjk_width) but for the historic understanding, it's
actually quite the other way round:
In traditional CJK character encodings, fonts, and terminal
applications, basically ALL characters were wide, including a subset
of Latin characters as it happened to be included in those character
sets, and sometimes even including the ASCII range.
These are the ones considered "ambiguous" since they used to be wide,
while in all non-CJK environments they are not (excluding ASCII which
is thus mirrored in the range "Halfwidth and Fullwidth Forms",
U+FF00 ... U+FF5E).
This also explains the chaotic mix of wide and narrow characters in ranges
like Latin-1 Supplement, Latin Extended, Greek and Cyrillic which is in no
way useful for any user; it's just a legacy compatibility issue.
I think the major usage for CJK users nowadays is about ranges like
Arrows, Enclosed Alphanumerics (with circled digits), Box Drawing etc.
>> And, I don't think that it is symmetrical. How about the following
>> patch? (I have not changed the name of modifier prefix)
>
> I'm not convinced that we need symmetry. ?It looks like a nice idea for
> Cygwin or newlib, given that the setlocale language string is checked
> and picked to pieces hardcoded in the loadlocale function.
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. 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 Lucida Typewriter.
(Although it occurs to me that in the case of Lucida Typewriter this
might be a bug since the wideness of ambiguous characters is just
simulated in this configuration rather than using wide font characters -
Andy, can you please check this?)
> 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 symmetry (which has no precedent in the locale arena) would
> require these systems to create yet another subdirectory or symlink for
> the same purpose. ?Even worse, if you propose that @cjkwide is a valid
> modifier for *any* language, you would make the whole mechanism on
> non-newlib based systems more complicated for no apparent reason.
The silly unmodular way that some systems implement the locale mechanism
(the worst of them being SunOS)
should not be an argument to not propagate a reasonable solution.
[Who was in favour of these double negations?]
The "locale interface" (syntax and semantics of LC_* strings) is defined
in a modular way and so the implementations should be - let them fix it.
Thomas
--
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/
- Raw text -