emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: buffer-swap-text and multibyteness


From: Kenichi Handa
Subject: Re: buffer-swap-text and multibyteness
Date: Tue, 10 Feb 2009 17:17:12 +0900

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

> > From: Kenichi Handa <address@hidden>
> > CC: address@hidden, address@hidden, address@hidden
> > Date: Mon, 09 Feb 2009 20:31:00 +0900
> > 
> > But, for instance, one edits a mail of:
> >    Content-type: text/plain; charset=iso-8859-1
> > and inserts a non-latin-1 character, we must use the
> > different encoding (utf-8 or the one selected by
> > select-message-coding-system), and modify content-type:
> > header.

> Did you try rmail-redecode-body after editing?

No, but it won't help because when I type C-c C-c after
editing, the unencodable characters disappear from the
buffer " *message-viewer RMAIL*".

> Anyway, I don't think the Babyl Rmail handled such a use case
> correctly, either.

No, it used to work because rmail-cease-edit didn't have to
encode the message.

> Why would one wish to insert a character into a
> message that cannot be encoded in the message's charset?  What would
> be the reason for such strange editing?

I got a Japanese mail with attachment file containing many
non-Japanese characters encoded by emacs-mule.  I editted
the mail, decoded the attached file by hand by the
combination of base64-decode-region and
decode-coding-region, and typed C-c C-c.

> All the use cases I can think of should be covered by
> rmail-redecode-body, which is The Right Way of changing
> the encoding of a message.

It works only if the unencodable characters is not lost in
the rmail file buffer.

---
Kenichi Handa
address@hidden







reply via email to

[Prev in Thread] Current Thread [Next in Thread]