Red Hat Bugzilla – Bug 78678
UTF8 stuff in site-start.el only looks at LANG
Last modified: 2015-01-07 19:01:54 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: When emacs is started it determines what coding system etc. to use depending on the locale settings. Then it uses the first of LC_ALL, LC_CTYPE and LANG with a non-empty value. /usr/share/emacs/site-lisp/site-start.el in emacs-21.2-18 does its own magic though, and then it only looks at LANG. That means that if you leave a default LANG of for example "sv_SE.UTF-8" but set LC_CTYPE to "sv_SE.ISO8859-1" emacs in Red Hat will use UTF-8 anyway. I think LC_CTYPE is supposed to have higher priority here. Anyway that's how emacs normally does it (without Red Hat's site-start.el). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. export LANG=sv_SE.UTF-8 2. export LC_CTYPE=sv_SE.ISO8859-1 3. emacs -q 4. C-h C RET [in emacs, to describe coding system] Actual Results: It says among other things Default coding system (for new files): u -- mule-utf-8 (alias: utf-8) Expected Results: I expected Default coding system (for new files): 1 -- iso-latin-1 (alias: iso-8859-1 latin-1) and that's what I get if I comment out the last sexp in site-start.el. Additional info: I use sv_SE locales in the instructions above only because that's what I used when encountering the bug. Nothing but the character set part of the locales should matter though.
Thank very much for the report. Will use LC_CTYPE in coming package release.
Should be fixed in emacs-21.2-24 in rawhide. Please confirm. :)
Oops, of course LC_CTYPE isn't usually defined! See bug 79535...
> When emacs is started it determines what coding system etc. > to use depending on the locale settings. Then it uses > the first of LC_ALL, LC_CTYPE and LANG with a non-empty value. Btw, I'm not sure how to see this -- at least it doesn't seem to do this for me. That's why those lines are in site-start.el AFAIK.
You can see it if you use locales that emacs is better at (try different ISO 8859 codes). I didn't mean to imply that UTF-8 works fine in a stock emacs without that stuff in site-start.el. Only that the same environment variables should be used as in emacs proper (in /usr/share/emacs/21.2/lisp/international/mule-cmds.el). (In emacs-21.2.27 it's still only LC_CTYPE and LANG, but not LC_ALL.) UTF-8 support is not enabled by default, even in UTF-8 locales. That is because the UTF-8 support isn't good enough. I see now that the UTF8 stuff in site-start.el is taken from the item in etc/PROBLEMS discussing this. (It is exactly because of the poor handling of UTF-8 in emacs I'm not ready to go over to UTF-8 locales yet.)
glibc documents LC_ALL as a macro, but I added it to site-start.el anyway in emacs-21.2-29. Please confirm utf-8 is working better now.
Closing.
Adding to blocker bug 185483 and adding IBM group permission.