Re: Need some help with Rmail/mbox

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ueno@unixuser.org,  pmr@pajato.com,  stephen@xemacs.org,  emacs-devel@gnu.org
> Date: Sun, 21 Sep 2008 18:07:10 -0400
> 
> >> >> The only reliable way to do decoding in buffers is by using
> >> >> the `destination' argument to decode-coding-region so that you can
> >> >> decode from a unibyte buffer into a multibyte buffer.
> >> > Why is that the only reliable method, and what do you suggest as the
> >> > value of `destination' argument for it to DTRT?
> >> As I said in my message: use the dest arg so as to "decode from
> >> a unibyte buffer into a multibyte buffer", so `destination' should be
> >> ... a multibyte buffer.
> > And the source a unibyte one?
> 
> Yes, of course.
> 
> >> As for why it's the only reliable method, it's because:
> >> >> Dealing with "bytes in a multibyte buffer" or with "non-ascii chars in
> >> >> a unibyte buffer" (as is necessarily the case either as source or as
> >> >> destination if you do the decoding in-place) is just too delicate in my
> >> >> experience (and of course, it's also somewhat inefficient).
> >> I'm not sure which part of the above paragraph is unclear.
> > The fact that other methods are not 100% reliable does not yet mean
> > that this one is.  I thought you had a more specific explanation why
> > this method is reliable.
> 
> No, I don't have such an explanation, except that the most natural input
> for decoding is a unibyte (string|buffer) and the most natural output is
> a multibyte (string|buffer).  I'd expect that to be pretty obvious.

That would mean Rmail/mbox will need to use another unibyte scratch
buffer for decoding MIME-encoded text: first qp- or b64-decode it into
another unibyte buffer, then decode-coding-region from there to the
(multibyte) display buffer.