Re: umlauts (8bit characters) input

[Stefan Monnier]

> dired-buffers with 'uuu' encoding -- and short and precise file names with

Please read the manual that explains what the "uuu" mean.

There are many places where things can go wrong and it helps if you
understand a bit of the possible different places.

E.g. the decoding of files, the decoding of file names, the decoding of
keyboard input, and the display of chars are 4 different and
independent issues.

> real umlauts! But in shell they're gone ... a bunch of control codes? (I
> am using tcsh and see a\314?o\314?u\314?\303?U\314?O\314?A\314?\342?\254
> instead of ���?����, shell has only 'uu-')

Could you try posting in a more widely available charset than mac-roman?
The last char of "uu-" is meaningless in a shell buffer (it's the encoding
of the file associated with the buffer, and since shell buffers have no
associated file, ...).

> The X11 client is even worse: copy and paste in this same Emacs does not
> work (a simple � is converted to a whole book volume of glyphs that are
> hard to describe),

Huh?  You mean you can't copy&paste from Emacs to itself correctly?
Or do you mean you can't correctly copy from Emacs to something else?
Or you can't correctly paste from something else to Emacs?

Please be super extra overly precise as if talking to complete idiots.

> and displays 'a<box>o<box>u...�', and shell uses no mode '--:**...' as in
> Terminal and shows the name as in Terminal.

The <box> just means that it couldn't find a font to display the char.
Go to that char and hit C-u C-x = to see which char it is.  Maybe you just
need to help Emacs find the right font.

But of course, first we need to know which Emacs version you're running.
If it's Emacs-CVS, please move this discussion to emacs-devel@gnu.org or
emacs-pretest-bug@gnu.org.


        Stefan