Re: buffer-swap-text and multibyteness

[Kenichi Handa <handa@m17n.org>]

In article <u8woesljv.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> 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:

ICAgICBBeCCgIKEgoiCjIKQgpSCmIKcgqCCpIKogqyCsIK0griCvCiAgICAgQnggsCCxILIgsyC0
ILUgtiC3ILgguSC6ILsgvCC9IL4gvwogICAgIEN4IMAgwSDCIMMgxCDFIMYgxyDIIMkgyiDLIMwg
zSDOIM8KICAgICBEeCDQINEg0iDTINQg1SDWINcg2CDZINog2yDcIN0g3iDfCiAgICAgRXgg4CDh
IOIg4yDkIOUg5iDnIOgg6SDqIOsg7CDtIO4g7wogICAgIEZ4IPAg8SDyIPMg9CD1IPYg9yD4IPkg
+iD7IPwg/SD+IP8K

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

---
Kenichi Handa
handa@m17n.org