Red Hat Bugzilla – Bug 86038
Danish special characters in Emacs fails
Last modified: 2015-01-07 19:04:28 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:
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"?
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!
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.
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?
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.
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
Also the emacs buffer in your screenshot in not in utf-8 encoding.
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.