On a clean 7.0 install, doing $ LANG=se_SV $ LC_CTYPE=se_SV $ export LANG LC_CTYPE $ emacs /tmp/edv.txt produces an error message "Opening input file: no such file or directory, /usr/lib/X11/locale/locale.alias" 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)
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!
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.
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 console. 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".
*** Bug 18642 has been marked as a duplicate of this bug. ***
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.
*** Bug 20279 has been marked as a duplicate of this bug. ***
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.