Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 78678 - UTF8 stuff in site-start.el only looks at LANG
Summary: UTF8 stuff in site-start.el only looks at LANG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: emacs
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2002-11-27 15:56 UTC by starback
Modified: 2015-01-08 00:01 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-20 07:24:22 UTC

Attachments (Terms of Use)

Description starback 2002-11-27 15:56:17 UTC
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

Version-Release number of selected component (if applicable):

How reproducible:

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

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 06:16:15 UTC
Thank very much for the report.  Will use LC_CTYPE in coming package

Comment 2 Jens Petersen 2002-12-18 08:03:49 UTC
Should be fixed in emacs-21.2-24 in rawhide.
Please confirm. :)

Comment 3 Jens Petersen 2003-01-03 12:41:34 UTC
Oops, of course LC_CTYPE isn't usually defined!
See bug 79535...

Comment 4 Jens Petersen 2003-01-03 13:13:08 UTC
> 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 15:08:13 UTC
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

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 19:37:15 UTC
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 07:24:22 UTC

Comment 8 David Lawrence 2006-04-24 19:02:30 UTC
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.