>>>> "Mike" == Mike FABIAN
> We'll have to have Ben explain that. I have no idea what
> rationale for that is. Given that most of that function seems
> to be intended to deal with Windows variance, possibly the
> whole thing is wrong-headed for Unix.
Mike> I'm sure this must be wrong. The LANG and the LC_* variables
Mike> should not be changed by XEmacs, just used as they are.
Wishful thinking. The POSIX locale concept is fundamentally broken in
a multilingual context, that's all there is to it. Even with the GNU
"local locale" extensions. Minimize changes to the environment and
make sure they're internally consistent, yes. But as long as a
multilingual application may find itself calling non-multilingual
programs, the only way it has to deal with the issue is to change the
Even the character set: consider the persistent breakage of Dired when
people have LANG set.
> No, LANG is the only variable touched by that code AFAICT.
> LC_* should be safe from it.
Mike> OK. But that means that when starting xemacs for example
Mike> like this
Mike> LANG=ja_JP.UTF-8 LC_COLLATE=ja_JP.UTF-8
Mike> LC_PAPER=en_US.UTF-8 xemacs
Mike> you would get a mixture of encodings in the LC_* variables
Mike> after XEmacs changed LANG, like this:
Yes. That is another bug in POSIX, I think. I guess you could hack
around it by parsing all LC_* variables found in the environment.
Mike> Such mixtures are not allowed. ``The Open Group Base
Mike> Specifications Issue 6'' says about this:
Like I said, POSIX locales are just plain broken. Consider the
Chinen> When LC_TIME=de_DE＠euro and LC_CTYPE=en_US.UTF-8, the
Chinen> multibyte character strings of month are not able to be
Chinen> converted into wide character. The reason why those
Chinen> strings are not is they have different encoding character
Chinen> from LC_CTYPE.
Note that Mule handles this kind of problem transparently.
I'm not saying we won't try to deal with this. I understand why the
Open Group found themselves forced into this position, and XEmacs is
too dependent on external processes for various services to take some
high-handed attitude that we are going to wait for the rest of the
world to do multilingual processing. But it's not easy to handle
POSIX rules without punting on "multilingual".
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.