Re: bug with start-process and start-process-shell-command

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 locale. Even the character set: consider the persistent breakage of Dired when people have LANG set. 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 sort(1) problem: 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.