From: Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Re: umlauts (8bit characters) input
Date: Wed, 02 Feb 2005 23:09:03 -0500 [thread overview]
Message-ID: <87is5auwfl.fsf-monnier+gnu.emacs.help@gnu.org> (raw)
In-Reply-To: mailman.578.1107374620.2841.help-gnu-emacs@gnu.org
[ 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
next prev parent reply other threads:[~2005-02-03 4:09 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-31 16:44 umlauts (8bit characters) input Hendrik Sattler
2005-01-31 21:52 ` Peter Dyballa
[not found] ` <mailman.226.1107211155.2841.help-gnu-emacs@gnu.org>
2005-01-31 22:44 ` Hendrik Sattler
2005-01-31 23:47 ` Peter Dyballa
[not found] ` <mailman.238.1107216437.2841.help-gnu-emacs@gnu.org>
2005-02-01 0:41 ` Hendrik Sattler
2005-02-01 10:31 ` Peter Dyballa
[not found] ` <mailman.279.1107254715.2841.help-gnu-emacs@gnu.org>
2005-02-01 11:37 ` Hendrik Sattler
2005-02-01 12:36 ` David Kastrup
2005-02-01 13:37 ` Hendrik Sattler
2005-02-01 15:25 ` Peter Dyballa
2005-02-02 10:27 ` Peter Dyballa
[not found] ` <mailman.463.1107343604.2841.help-gnu-emacs@gnu.org>
2005-02-02 12:38 ` David Kastrup
2005-02-02 13:12 ` Peter Dyballa
[not found] ` <mailman.482.1107350962.2841.help-gnu-emacs@gnu.org>
2005-02-02 14:10 ` David Kastrup
2005-02-02 14:59 ` Ismael Valladolid Torres
2005-02-02 18:21 ` Peter Dyballa
2005-02-02 18:17 ` Peter Dyballa
2005-02-02 15:19 ` Stefan Monnier
2005-02-02 19:37 ` Peter Dyballa
[not found] ` <mailman.578.1107374620.2841.help-gnu-emacs@gnu.org>
2005-02-03 4:09 ` Stefan Monnier [this message]
2005-02-01 13:07 ` Reiner Steib
2005-02-01 13:47 ` Hendrik Sattler
2005-02-01 15:21 ` Peter Dyballa
2005-02-01 15:50 ` Hendrik Sattler
2005-02-01 16:05 ` David Kastrup
2005-02-01 16:08 ` Hendrik Sattler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87is5auwfl.fsf-monnier+gnu.emacs.help@gnu.org \
--to=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).