Re: umlauts (8bit characters) input

[Stefan Monnier]

[ Since you're using an Emacs-CVS version, then please, as I mentioned in
  my previous message, move this discussion elsewhere. ]

>> 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, ...).

> Sorry, this is no mac-roman,

Tell that to your mailer:

Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=X-MAC-ROMAN-LATIN1; format=flowed
Content-Transfer-Encoding: quoted-printable

> it's exactly what I see in xterm or in Terminal in the shell buffer --
> although I should see something different: äöüßÜÖÄ€.  That's the file's
> name. (Mail.app claims that it is using a 7bit encoding.)

[ This time I do see your non-ASCII chars properly, and the message is
  labelled as Content-Type: text/plain; charset=WINDOWS-1252; format=flowed ]

Actually, 7bit encoding (i.e. quoted-printable or base64) has nothing to do
with charset encoding.

>>> 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?

> My .emacs file is only 8bit, so I chose ISO Latin-15. In its header it is
> explicitly written
> ;;; -*- mode: Emacs-Lisp; coding: iso-8859-15; -*-

This has no influence on the behavior of Emacs, other than how it reads this
particular file.

> When I copy a string with characters from this set via double-clicking the
> selection and paste it either in the same or in the (Unicode) scratch buffer
> the simple accented chars become each a series of this character and mostly
> \216 -- me and others have seen similiar things in GNOME under Linux when
> copying from outside GNU Emacs. Pressing umlauts etc. on my keyboard enter
> exactly these umlauts into the buffers. C-x = explains in hex that they're
> taken from the usual code positions (for example Ä is 0x8c4, ä is 0x8e4).

What are you waiting for to M-x report-emacs-bug ?

> I can send you a snapshot privately ...

That wouldn't do you any good.

>>> 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.

> There is no char.

Oh, yes, there sure is: that's what the box stands for.

> So there should not be a box. The correct string is
> äöüß... and as it's a file name, it's UTF-8 encoded. (Since the displayed
> glyphs are the chars stripped off their diaeresis the box could be ...
> but it's : "(01211310, 332488, 0x512c8, file ...).

You forgot the C-u before the C-x =

> A bit astronomical high.

What makes you think so?

> æ and Æ and € are represented by themselves.

When we're talking about non-ASCII chars, there's simply no such thing as
"represented by themselves".

>> 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.

> Since the Fink team decided to distribute in the unstable section an Emacs
> from CVS ... (but there was not much difference to 21.3.50, it might be
> exactly 0 in this case)

You didn't finish your