Bug 18548 - national (accented) characters are not displayed
Summary: national (accented) characters are not displayed
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: emacs   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: Aaron Brown
: 18642 20279 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-06 16:52 UTC by daniel.deimert
Modified: 2007-04-18 16:29 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-10-10 20:55:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description daniel.deimert 2000-10-06 16:52:52 UTC
On a clean 7.0 install, doing

$ LANG=se_SV
$ export LANG LC_CTYPE
$ emacs /tmp/edv.txt

produces an error message "Opening input file: no such file or directory,
which is no wonder because the locale.alias file is in /usr/share/locale

Also, national European accented characters such as edv EDV does not work
but are displayed as "edv EDV" (which corresponds to the iso-8859-1
character codes for edv with the 8th bit stripped off)

Comment 1 daniel.deimert 2000-10-06 16:56:46 UTC
I wonder if I should file a bugzilla bug report for not displaying our beloved
accented national characters as well. The "edv EDV" stuff above should be
latin-1. You'll have to add the 8th bit to the character codes yourself. You're
hackers, you'll work it out. Bork bork bork!

Comment 2 Trond Eivind Glomsrxd 2000-10-08 02:05:16 UTC
There are two of these  files, not just one... Somehow, the nox package wants
the one in X package and not the one in glibc even though it's not linked with
it. Argh. If you install the XFree86 package, it should work just fine.

As for the accents, please remember to file bugs separately. When you do, please
have more information available... what is edv EDV? For what it's worth,
iso-accents-mode with `'"~ and character seems to work just fine here.

Comment 3 daniel.deimert 2000-10-08 13:15:40 UTC
You are right about X. If the keyboard is set to latin1, I can enter \345 \344
\366 using the keyboard in bash, but not in emacs.  If X is installed, emacs
accepts (and displays) the correct symbols on screen.
I have a feeling the missing locale file is what's causing emacs to fail when
using the accented characters, thats' why its in the same bug report. 

The edv EDV stuff are the accented characters \345 \344 \366 (octal) which
accidentaly got masked with 0x7f in bugzilla.   They are three common Swedish
vowels.  iso-accents-mode does part of the job but it doesn't fix the problem;
e.g. I can input \366 by typing "o and then M-x iso-accentuate, but it is still
displayed in emacs as \366, not as an accented o.  This is on a local text-mode

If I telnet into the host from a RH7 host with X installed (and where emacs
works locally), and fire up emacs on the remote host in the telnet window, I get
the "no such file" error message, and if I then press any of the vowel keys that
generates \345 \344 \366 keycodes, the remote emacs seems to think that the
vowels are page up/down keys and I get error messages like "End of buffer" or
"Beginning of buffer". 

Comment 4 Trond Eivind Glomsrxd 2000-10-10 20:51:07 UTC
*** Bug 18642 has been marked as a duplicate of this bug. ***

Comment 5 Trond Eivind Glomsrxd 2000-10-11 03:08:59 UTC
It would work  if you copied the X11 locale.alias there.... the files are not
identical. The glibc one works in console, but not in xterm. Fixed in -17 which
eventually will show up in Rawhide - I include the locale.alias file in the rpm,
and patch the startup sequence. Ugh.

Comment 6 Trond Eivind Glomsrxd 2000-11-03 15:04:05 UTC
*** Bug 20279 has been marked as a duplicate of this bug. ***

Comment 7 Mikael Puittinen 2000-11-03 15:09:02 UTC
If you want to keep the server installation as clean as possible and
not have to install XFree,

ln -sf /usr/share/locale /usr/lib/X11 

seems to do the job.

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