Re: buffer-swap-text and multibyteness

[Kenichi Handa <handa@m17n.org>]

In article <umycvs6a0.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > From: Kenichi Handa <handa@m17n.org>
> > CC: eliz@gnu.org, rms@gnu.org, emacs-devel@gnu.org
> > 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
handa@m17n.org