* Florian v. Savigny (lorian@fsavigny.de) [28.02.09 18:39]:
> 
> Hi Sebastian,
> 
>   > > But Emacs displays the lower-case umlauts followed by a space
>   > > etc. etc. ...
> 
>   > what does file say about the offending files?
> 
> I was not actually talking about files when I mentioned Emacs, but
> what I see when I *type* into Emacs (such as in this mail
> message). But in case you mean what that produces when I save the
> result of what I typed into a file, I ran a few tests, and the results
> were mixed:
> 
> For the 3 lower-case umlauts, file reports UTF-8, consistent with the
> number of bytes (i.e. the file length): 3 characters, 6 bytes. The hex
> representation of the 6 bytes is: c3 a4 c3 b6 c3 3c.
> 
> For the three upper-case umlauts and for the eszett, file reports
> iso-8859, also consistent with the number of bytes: 3 characters, 3
> bytes. The code position is, however, definitely wrong: it is always
> hex c3 (which would be the upper-case A tilde in iso-8859-1, and four
> different letters can hardly have the same code position.)
> 
> To me this looks as if Emacs puts the first half of the byte sequences
> (always the hex c3) into the buffer, while trying to interpret the
> other half (see list below) as a command: it will say something like
> "\204 is undefined". I am quite certain \nnn is an octal number.
> 
> eszett: \237 (hex 9f, dec 159)
> A uml: \204 (hex 84, dec 132)
> O uml: \226 (hex 96, dec 150)
> Uuml: \234 (hex 9c, dec 156)
> 
> If I am right, the keys thus send:
> 
> eszett: c3 9f
> A uml: c3 84
> O uml: c3 96
> U uml: c3 9c
> a uml: c3 a4
> o uml: c3 b6
> u uml: c3 3c
> 
> I would assume that these sequences are the UTF-8 representation of
> the respective characters (but I don't have a table to figure that
> out).
> 
> Sorry if the whole thing was diffcult to follow. I should perhaps have
> mentioned that for the upper-case umlauts and the eszett, Emacs not
> only complains, but also inputs an "unknown" character into the
> buffer, represented by a '?' in reverse video. That's apparently the
> hex c3 byte.
> 
That is a problem of the consolefont, since the console can't display it 
with cp1250...


>   > Emacs always uses the enconding of the file, where as an redirect
>   > uses the locale, iirc.
> 
> I know; normally it can figure it out - I think this ability is not
> compromised in any way (I can e.g. open an XML file encoded in utf-8,
> and will see "11u" in the mode line). Also, please note that under X,
> Emacs behaves completely as before.
> 
> By "redirect", you mean shell redirection?  Does that do any character
> conversion?

yes.

echo "äöüÄÖÜß" > console.test
then write the same in emacs and save as emacs.test.

And then compare the output of

file console.test
and
file emace.test

If there are differences, somewhere here lies the Problem

> 
>   > I assume you know the options->mule menu in emacs, there is a lot to
>   > help with encoding issues...
> 
> Yes, I know, but I don't see how set-input-method would fix this. Do you?
> 
No but set-coding-system for saving the file might help to achieve the 
right encoding.

>   > > As to the locale, where can I look that up ... ?
>   > .bashrc
> 
> Neither ~/.bashrc nor /etc/bash/bashrc contain any locale setting
> ... hmm.

locale 
should shown it to you

> 
> But very frankly, would the solution not focus on the kernel, at least
> partly? As I said, I can reverse the phenomenon by simply booting the
> old kernel!
> 
> Does nobody know where the kernel controls what the keys of the
> console keyboard send when pressed?
> 
> (BTW, KEYMAP="de-latin1-nodeadkeys", in /etc/conf.d/keymaps.)

Exactly there.

> 
> Regards, Florian
> 
> 
> 

Sebastian

-- 
 " Religion ist das Opium des Volkes. "      Karl Marx

 SEB@STI@N GÜNTHER         mailto:samson@guenther-roetgen.de