Bug 78678 - UTF8 stuff in site-start.el only looks at LANG
UTF8 stuff in site-start.el only looks at LANG
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: emacs (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-27 10:56 EST by starback
Modified: 2015-01-07 19:01 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-20 02:24:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description starback 2002-11-27 10:56:17 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.
Comment 1 Jens Petersen 2002-11-28 01:16:15 EST
Thank very much for the report.  Will use LC_CTYPE in coming package
release.
Comment 2 Jens Petersen 2002-12-18 03:03:49 EST
Should be fixed in emacs-21.2-24 in rawhide.
Please confirm. :)
Comment 3 Jens Petersen 2003-01-03 07:41:34 EST
Oops, of course LC_CTYPE isn't usually defined!
See bug 79535...
Comment 4 Jens Petersen 2003-01-03 08:13:08 EST
> 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.
Comment 5 starback 2003-01-06 10:08:13 EST
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.)
Comment 6 Jens Petersen 2003-01-16 14:37:15 EST
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.
Comment 7 Jens Petersen 2003-02-20 02:24:22 EST
Closing.
Comment 8 David Lawrence 2006-04-24 15:02:30 EDT
Adding to blocker bug 185483 and adding IBM group permission.

Note You need to log in before you can comment on or make changes to this bug.