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 86038 - Danish special characters in Emacs fails
Summary: Danish special characters in Emacs fails
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: emacs
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-12 20:10 UTC by Kristian Sørensen
Modified: 2015-01-08 00:04 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-05-20 06:53:56 UTC


Attachments (Terms of Use)

Description Kristian Sørensen 2003-03-12 20:10:31 UTC
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 13:20:59 UTC
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 12:23:43 UTC
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 14:38:30 UTC
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 19:20:19 UTC
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 20:00:46 UTC
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 04:19:09 UTC
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 04:20:00 UTC
Also the emacs buffer in your screenshot in not in utf-8 encoding.

Comment 8 Jens Petersen 2003-04-17 13:15:28 UTC
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.