Aidan Kehoe <kehoea(a)parhasard.net&gt; さんは書きました: OK, you are right, with that option it works. I think that should be the default when running in an UTF-8 locale. I think XEmacs should set useful defaults depending on the locale used in the system when XEmacs was started. Currently this is not the case at all and I need a lot of strange code in my ~/.xemacs/init.el to get reasonable settings. Let me try to explain the problems I am experiencing and how I work around them, maybe that helps to fix it properly. The first big problem is that 'set-language-environment' changes the locale specific environment variables. I think this doesn't make any sense, if my system runs by default in ja_JP.UTF-8 locale, I certainly don't want that (set-language-environment "Japanese") sets ja_JP.eucJP locale again. This will give the wrong defaults for all processes started by XEmacs and causes a lot of headache. My workaround for this problem looks like this: (when (and (string-match "XEmacs" emacs-version) (emacs-version>= 21 5 6)) (setq mike-old-lang (getenv "LANG"))) (when (and (getenv "LANG") (string-match "ja" (getenv "LANG"))) (set-language-environment "Japanese")) (when (and (string-match "XEmacs" emacs-version) (emacs-version>= 21 5 6)) (setenv "LANG" mike-old-lang) (set-current-locale mike-old-lang)) I.e. I remember the old value of LANG, set it again after 'set-language-environment' and call 'set-current-locale' again to revert the locale settings to what they were before 'set-language-environment'. XEmacs 21.4.x did not change the locale specific environment variables when calling 'set-language-environment' which is much better in my opinion. 'set-language-environment' should neither change these environment variables nor call setlocale(). I cannot just omit the call to 'set-language-environment' because in that case I get Japanese displayed partly with Chinese fonts, i.e I see a Japanese text in a weird mixture of Japanese and Chinese fonts like in this screen shot: http://www.suse.de/~mfabian/misc/xemacs-20050113/xemacs-japanese-chinese-... But calling 'set-language-environment' messes up my locale settings, therefore I have to use the above workaround to return to the correct settings again. I have only LANG set, I have neither set any LC_* variables nor LC_ALL, I had set these as well I probably would have to remember and restore them as well. Another nasty side effect of (set-language-environment "Japanese") is that I sets the coding system alias for 'native to 'euc-jp which is also bad if I run in ja_JP.UTF-8 locale. After calling 'set-language-environment', many settings for coding systems are still not correct, especially not in UTF-8 locales. I try to fix this with the following code in my ~/.xemacs/init.el: (defun mike-set-coding-systems () (interactive) (let* ((tmp (shell-command-to-string "locale charmap")) (tmp (substring tmp 0 (string-match "\[ \t\n\]" tmp))) (tmp (downcase tmp))) (when (or (and (fboundp 'find-coding-system) ; XEmacs only (find-coding-system (intern tmp))) ;; Emacs: (coding-system-p (intern tmp))) ;; set the coding system priorities: ;; (this is also important to make XIM in utf-8 work for XEmacs ;; because XEmacs has no variable/function to set the ;; coding-system for XIM, it is just autodetected which ;; will work correctly only when the coding-system priorities ;; are OK.) (if (not (and (string-match "XEmacs" emacs-version) (string-match "utf-8" tmp))) (prefer-coding-system (intern tmp)) ;; it's strange, but (prefer-coding-system 'utf-8) doesn't ;; work in XEmacs. ;; use 'set-coding-priority-list instead, which achieves ;; the same and works for 'utf-8 as well: (set-coding-priority-list (list (intern tmp))) (set-coding-category-system (intern tmp) (intern tmp))) (if (and (string-match "XEmacs" emacs-version) (emacs-version>= 21 5 6)) ;; XEmacs 21.5 apparently renamed this function: (set-default-output-coding-systems (intern tmp)) (set-default-coding-systems (intern tmp))) (set-keyboard-coding-system (intern tmp)) (set-terminal-coding-system (intern tmp)) ;; XEmacs 21.5.16 needs this to be able to use non-ASCII file names: (if (and (string-match "XEmacs" emacs-version) (emacs-version>= 21 5 6)) (setq file-name-coding-system (intern tmp))) ;; without the following line, shell buffers are not by default ;; in UTF-8 when running in an UTF-8 locale in XEmacs 21.5.16: (setq process-coding-system-alist (cons (cons ".*" (intern tmp)) '())) ;; these two lines appearently make no difference, if they ;; are used instead of the above process-coding-system-alist, ;; shell buffers still have the wrong encoding: ;; (setq default-process-coding-system-read (intern tmp)) ;; (setq default-process-coding-system-write (intern tmp)) ;; and this doesn't seem to work either: ;; (setq default-process-coding-system '(utf-8 . utf-8)) ;; ;; the following is necessary to enable XEmacs to pass ;; command line arguments to external processes in the correct ;; encoding. For example this is needed to make ;; 'M-x grep' work when searching for UTF-8 strings ;; while running in an UTF-8 locale. ;; (if (and (string-match "XEmacs" emacs-version) (emacs-version>= 21 5 6)) (define-coding-system-alias 'native (intern tmp))) (when (and (string-match "XEmacs" emacs-version) (locate-library "lookup") (string-match "utf-8" tmp)) ;; It seems that lookup must loaded before the ;; lookup-process-coding-system can be changed. (require 'lookup) (setq lookup-process-coding-system 'utf-8))))) (mike-set-coding-systems) It is very strange that such a lot of setup is needed in ja_JP.UTF-8. Especially when upgrading from XEmacs 21.4.x to XEmacs 21.5.x, suddenly many things don't work anymore. And it is very difficult to find out which variables need to be set to repair it again. Maybe most of that could be set correctly by default? -- Mike FABIAN <mfabian(a)suse.de&gt; http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; さんは書きました: I'm sure this must be wrong. The LANG and the LC_* variables should not be changed by XEmacs, just used as they are. OK. But that means that when starting xemacs for example like this LANG=ja_JP.UTF-8 LC_COLLATE=ja_JP.UTF-8 LC_PAPER=en_US.UTF-8 xemacs you would get a mixture of encodings in the LC_* variables after XEmacs changed LANG, like this: mfabian＠magellan:~$ LANG=ja_JP.eucJP LC_COLLATE=ja_JP.UTF-8 LC_PAPER=en_US.UTF-8 locale LANG=ja_JP.eucJP LC_CTYPE="ja_JP.eucJP" LC_NUMERIC="ja_JP.eucJP" LC_TIME="ja_JP.eucJP" LC_COLLATE=ja_JP.UTF-8 LC_MONETARY="ja_JP.eucJP" LC_MESSAGES="ja_JP.eucJP" LC_PAPER=en_US.UTF-8 LC_NAME="ja_JP.eucJP" LC_ADDRESS="ja_JP.eucJP" LC_TELEPHONE="ja_JP.eucJP" LC_MEASUREMENT="ja_JP.eucJP" LC_IDENTIFICATION="ja_JP.eucJP" LC_ALL= mfabian＠magellan:~$ Such mixtures are not allowed. ``The Open Group Base Specifications Issue 6'' says about this: If different character sets are used by the locale categories, the results achieved by an application utilizing these categories are undefined. (see http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap07.html) In the worst case, applications may even crash. I remember a bug report concerning "sort" where "sort" aborted when LC_TIME and LC_CTYPE were set to locales with different encodings: (SuSE Bugzilla http://bugzilla.suse.de/show_bug.cgi?id=26506) When starting sort like this, 1. unset all LC_* variables. Unset LANG (or set to POSIX) 2. echo -e "l4\nl3" | LC_TIME=de_DE＠euro LC_CTYPE=en_US.UTF-8 sort if failed with a message like sort: sort.c:717: inittables_mb: Assertion `mblength != (size_t)-1 && mblength != (size_t)-2' failed. Aborted This was a bug in sort which was fixed by Mitsuru Chinen: Chinen> Additional Comment #8 From Mitsuru Chinen 2003-07-16 05:07 Chinen> Chinen> Hello all, Chinen> Chinen> sort utility stores the multibyte character strings of months Chinen> into buffers at first. This behavior is for `-M' option Chinen> (i.e. compare acccording to month.) At that time, the month Chinen> multibyte character stirngs are converted into a wide Chinen> character string in order to ignore the different of uppercase Chinen> and lowercase. Chinen> 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 strings Chinen> are not is they have different encoding character from Chinen> LC_CTYPE. Chinen> Chinen> I'll make a patch not to initialize the string of month when Chinen> `-M' option is not specified. But I will not support the case Chinen> where `-M' option is specified and the value of LC_TIME is Chinen> different from the one of LC_CTYPE. I think supporting such a Chinen> case is difficult by the above-mentioned reason. (The Single Chinen> Unix specification also says the following: → see ``The Open Group Base Specifications Issue 6'' above. -- Mike FABIAN <mfabian(a)suse.de&gt; http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。