Bug 78678
| Summary: | UTF8 stuff in site-start.el only looks at LANG | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | starback |
| Component: | emacs | Assignee: | Jens Petersen <petersen> |
| Status: | CLOSED RAWHIDE | QA Contact: | Jay Turner <jturner> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | mitr, srevivo |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-02-20 07:24:22 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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.