[Top][All Lists]

[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 20:52:00 +0900

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

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

> Do you have an idea why they disappeared?

It's because the encoding routine produces a default
character for such an unencodable character.  Raising an
error signal for such a case in the deep place of encoding
routine is in my todo list and not yet implemented.

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

> I do this a lot, but I don't use decode-coding-region.  I use
> base64-decode-region, then type "C-c C-c" followed by "M-x
> rmail-redecode-body RET".  This did work for me after the last series
> of changes in Rmail.  If it doesn't work for you with the current CVS,
> can you somehow forward to me the original message, before your
> editing, so I could try reproducing what you did?

rmail-redecode-body works only when the whole message body
is encoded by a single coding system, which is not the case
in my scenario above.

Please try your method with this mail.

Here, I enter Japanese "Hello":

And, here I enter base64-encoded Latin-1 text:


And, I send this message itself using charset=iso-2022-jp.

Kenichi Handa

reply via email to

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