Bug 86038 - Danish special characters in Emacs fails
Danish special characters in Emacs fails
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: emacs (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-12 15:10 EST by Kristian Sørensen
Modified: 2015-01-07 19:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-20 02:53:56 EDT
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 Kristian Sørensen 2003-03-12 15:10:31 EST
Description of problem:
The Danish characters "aring", "ae" and "oslash" does not work in Emacs. Some
strange symbols come instead... :-/

My keyboard layout is danish (dk-latin1)

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


How reproducible:
Switch keyboard layout to dk-latin1, open emacs and enter some of the danish
symbols... (they are near to the ENTER key)... the keys will return rubbish!


Steps to Reproduce:
1.
2.
3.
    
Actual results:


Expected results:


Additional info:
Comment 1 Jens Petersen 2003-03-20 08:20:59 EST
Ermm, looks ok to me.  I guess you have to give me more
information on how exactly to reproduce this.

This is what I did to test:
0) set Danish Latin1 kbd with redhat-config-keyboard
1) start a Danish gnome session from gdm
2) start Emacs and note that the "*scratch*" is in utf-8 encoding ("u")
3) enter aa, ae and oe without any problems

What is the output of "locale"?
Comment 2 Kristian Sørensen 2003-03-23 07:23:43 EST
Hi again! The bug is still here.

I have tried as several users: with my own (old) dot-files and as a total new
user-profile on the system. Still with the same result. I have made a
screen-shot for you here:
http://www.cs.auc.dk/~ks/phoebe-emacs-danish-problem.png

I get the error regardless of it is a Danish or English Gnome-session - and
wether or not it is "Danish latin1" or "Danish" keybord layout.

You asked for the locale output - here you go:
-- locale output --
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=


I hope we can find an solution to the problem!
Comment 3 Kristian Sørensen 2003-03-23 09:38:30 EST
Just a note:

I have just compiled emacs-21.3, and now there is no problems using the Danish
ae, oslash and aring any more ... my guess is just that something went wrong
when compiling the RPM-package for Phoebe.
Comment 4 Jens Petersen 2003-04-07 15:20:19 EDT
I see.  (emacs-21.3 should be in rawhide shortly btw.)

What does the output of "C-h C RET" look like in your emacs-21.2 session?
Comment 5 Kristian Sørensen 2003-04-08 16:00:46 EDT
For the key-strokes you wrote we get this result:

- - - - - - - - - - - 
Coding system for saving this buffer:
  Not set locally, use the default.
Default coding system (for new files):
  nil
Coding system for keyboard input:
  nil
Coding system for terminal output:
  nil
Defaults for subprocess I/O:
  decoding: - -- undecided (alias: unix dos mac)
  encoding: 1 -- iso-latin-1 (alias: iso-8859-1 latin-1)

Priority order for recognizing coding systems when reading files:
  1. iso-latin-1 (alias: iso-8859-1 latin-1)
  2. iso-2022-jp (alias: junet)
  3. iso-2022-7bit 
  4. iso-2022-7bit-lock (alias: iso-2022-int-1)
  5. iso-2022-8bit-ss2 
  6. emacs-mule 
  7. raw-text 
  8. japanese-shift-jis (alias: shift_jis sjis)
  9. chinese-big5 (alias: big5 cn-big5)
  10. no-conversion (alias: binary)
  11. mule-utf-8 (alias: utf-8)

  Other coding systems cannot be distinguished automatically
  from these, and therefore cannot be recognized automatically
  with the present coding system priorities.

  The followings are decoded correctly but recognized as iso-2022-7bit-lock:
    iso-2022-7bit-ss2 iso-2022-7bit-lock-ss2 iso-2022-cn iso-2022-cn-ext
    iso-2022-jp-2 iso-2022-kr

Particular coding systems specified for certain file names:

  OPERATION	TARGET PATTERN		CODING SYSTEM(s)
  ---------	--------------		----------------
  File I/O		"\\.po\\'\\|\\.po\\."	po-find-file-coding-system
				"\\.elc\\'"				(emacs-mule . emacs-mule)
				"\\(\\`\\|/\\)loaddefs.el\\'"
										(raw-text . raw-text-unix)
				"\\.tar\\'"				(no-conversion . no-conversion)
				""						(undecided)
  Process I/O	nothing specified
  Network I/O	nothing specified
- - - - - - - - - - - 

Cheers, KS.
Comment 6 Jens Petersen 2003-04-09 00:19:09 EDT
Oh, because with "LANG=en_US.UTF-8 emacs -q" I get the following output:


Coding system for saving this buffer:
  Not set locally, use the default.
Default coding system (for new files):
  u -- mule-utf-8 (alias: utf-8)
Coding system for keyboard input:
  u -- utf-8 (alias of mule-utf-8)
Coding system for terminal output:
  u -- utf-8 (alias of mule-utf-8)
Defaults for subprocess I/O:
  decoding: u -- mule-utf-8 (alias: utf-8)
  encoding: u -- mule-utf-8 (alias: utf-8)

Priority order for recognizing coding systems when reading files:
  1. mule-utf-8 (alias: utf-8)
  2. iso-latin-1 (alias: iso-8859-1 latin-1)
  3. iso-2022-jp (alias: junet)
  4. iso-2022-7bit 
  5. iso-2022-7bit-lock (alias: iso-2022-int-1)
  6. iso-2022-8bit-ss2 
  7. emacs-mule 
  8. raw-text 
  9. japanese-shift-jis (alias: shift_jis sjis)
  10. chinese-big5 (alias: big5 cn-big5)
  11. no-conversion (alias: binary)

  Other coding systems cannot be distinguished automatically
  from these, and therefore cannot be recognized automatically
  with the present coding system priorities.

  The followings are decoded correctly but recognized as iso-2022-7bit-lock:
    iso-2022-7bit-ss2 iso-2022-7bit-lock-ss2 iso-2022-cn iso-2022-cn-ext
    iso-2022-jp-2 iso-2022-kr

Particular coding systems specified for certain file names:

  OPERATION	TARGET PATTERN		CODING SYSTEM(s)
  ---------	--------------		----------------
  File I/O	"\\.po\\'\\|\\.po\\."	po-find-file-coding-system
		"\\.elc\\'"		(emacs-mule . emacs-mule)
		"\\(\\`\\|/\\)loaddefs.el\\'"
					(raw-text . raw-text-unix)
		"\\.tar\\'"		(no-conversion . no-conversion)
		""			(undecided)
  Process I/O	nothing specified
  Network I/O	nothing specified
Comment 7 Jens Petersen 2003-04-09 00:20:00 EDT
Also the emacs buffer in your screenshot in not in utf-8 encoding.
Comment 8 Jens Petersen 2003-04-17 09:15:28 EDT
Btw the default utf-8 support in 21.3 is much improved,
but it looks like you weren't loading site-start.el somehow?

emacs-21.3-2 shortly to be in rawhide has further
improvements in the utf-8 setup.

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