Bug 79535 - Emacs utf8 input broken
Summary: Emacs utf8 input broken
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: emacs
Version: 1.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Jay Turner
URL:
Whiteboard:
Keywords:
: 80246 80725 (view as bug list)
Depends On:
Blocks: 79579
TreeView+ depends on / blocked
 
Reported: 2002-12-12 20:25 UTC by Nicolas Mailhot
Modified: 2015-01-08 00:02 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2003-01-06 00:25:13 UTC


Attachments (Terms of Use)
picture (11.54 KB, image/png)
2002-12-12 20:39 UTC, Nicolas Mailhot
no flags Details

Description Nicolas Mailhot 2002-12-12 20:25:32 UTC
I've just tried emacs on a clean rawhide system (axed .emacs to get default RH
config). It is totally broken by the utf8 locale. For example :

i -> C)
` -> C 
$ -> b,
g -> C'

and so on. Seems every character that is not pure ascii is mangled in a
multibyte blob. This makes emacs almost useless for non-english european languages:(

Comment 1 Nicolas Mailhot 2002-12-12 20:32:43 UTC
Seems bugzilla is no better.
I'll attach a picture to be clear

Comment 2 Nicolas Mailhot 2002-12-12 20:39:27 UTC
Created attachment 88664 [details]
picture

Comment 3 Jens Petersen 2002-12-17 10:55:04 UTC
Presumably you're inputting the chanracters with a French keyboard?

Comment 4 Nicolas Mailhot 2002-12-17 11:01:00 UTC
Yes (it more or less works on the same system with xemacs).
Note that I do not see this on a similar system with dotfiles dating from at
least 7.0, so it may be just a problem of emacs defaults not adapted from utf8.

I can check again the broken system this evening, if you have any specific test
in mind.

Comment 5 Nicolas Mailhot 2002-12-17 11:03:19 UTC
And as usual gedit input shines.
quite a pity it's too light-weight to be used for any serious work.

Comment 6 Nicolas Mailhot 2002-12-19 23:17:46 UTC
Just to be sure I created a new virgin user and his emacs was broken too.

So this is definitely not caused by any weird user setting

Comment 7 Jens Petersen 2002-12-20 07:08:29 UTC
It would be useful to know what happens in the following cases:

(a) you run "emacs -q --no-site-file" (this is probably the most interesting)

(b) you run "emacs --unibyte"

(c) you run "emacs --multibyte" (but I think this is the default)

(d) also how about "emacs -nw" in a terminal


Comment 8 Nicolas Mailhot 2002-12-20 19:11:32 UTC
(a) and (c) do not change anything

(b) gives \123-style numbers

(d) breaks horribly (instead of printing garbage all non ascii-keys are mapped
to emacs functions (euro for example gives the message « No M-x tags-search or
M-x tags-query-replace in progress »)

(tested on another new user)

Its also not a font problem, I tried to use a known good font ant it gave me the
same garbage (it another style and size, so I'm sure it did use the requested font)

###############################################
### Current Status of Multilingual Features ###
###############################################

CONTENTS: Section 1.  General Information
          Section 2.  Display
          Section 3.  Input methods
          Section 4.  Coding systems
          Section 5.  Character sets
          Section 6.  Fontsets

########################################
# Section 1.  General Information
########################################

Version of this emacs:
  GNU Emacs 21.2.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-12-02 on stripples.devel.redhat.com

Configuration options:
   --host=i386-redhat-linux --build=i386-redhat-linux
--target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --with-gcc --with-pop --with-sound

Multibyte characters awareness:
  default: t
  current-buffer: t

Current language environment: English

########################################
# Section 2.  Display
########################################

Window-system: x11

The selected frame is using the font:
	-monotype-andale mono-medium-r-normal--27-180-100-107-m-150-iso8859-1


Comment 9 Jens Petersen 2003-01-03 12:37:36 UTC
*** Bug 80246 has been marked as a duplicate of this bug. ***

Comment 10 Jens Petersen 2003-01-03 12:38:45 UTC
*** Bug 80725 has been marked as a duplicate of this bug. ***

Comment 11 Jens Petersen 2003-01-03 12:46:51 UTC
I suspect this was probably caused by the change made to
site-start.el for bug 78678.

Since LC_CTYPE isn't defined by default, LANG should be used (as in Psyche)
if LC_CTYPE isn't set .

Comment 12 Jens Petersen 2003-01-03 13:15:50 UTC
Should be fixed hopefully in emacs-21.2-27, which
should be in rawhide before too long.

Comment 13 Nicolas Mailhot 2003-01-06 00:25:13 UTC
It works for me at least with emacs-21.2-27 now. Even with strange new
characters like Å/Å (OE/oe)

Thanks a lot

Comment 14 Nicolas Mailhot 2003-01-06 00:27:56 UTC
(I had to set a more complete face as default to get oe to work since adobe
courier is a bit lacking on this respect)

Comment 15 Jens Petersen 2003-01-06 02:31:49 UTC
That is interesting.  What is the default face you're using now?

Comment 16 Nicolas Mailhot 2003-01-06 10:53:46 UTC
I'm afraid I only use corefonts from SF since I've given up on XFree86 providing
complete non-ascii fonts for quite a while.

However I didn't check for a long time, so maybe the provided fonts are a bit
better now 

Comment 17 starback 2003-01-06 13:28:24 UTC
I've always used intlfonts to get all fonts emacs needs, and have never
understood why Red Hat doesn't include it.


Comment 18 Jens Petersen 2003-02-19 14:50:38 UTC
Could you please put in a separate RFE request for intlfonts?
Thank you.


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