Re: improve rmail's MIME handling

[Kenichi Handa <handa@m17n.org>]

In article <jwvoc9umwyz.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > patch for summary lines.  Nowadays, not handling MIME
> > properly is regarded as a bug, and thus I want to install it
> > for Emacs 23.  What do you think?

> I'd agree.

In article <87y68xmbec.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:

> Please go ahead.  Thanks.

Ok.  I've just installed changes which are bigger than what
I expected at first.  I first thought that we could use the
code in rmailmm.el almost directly, but found some problems.
Among them, these were fairly big problems:

(1) It doesn't handle a nested multipart which typically
    happen in a message that contains forwarded multipart
    message.

(2) Handling of a message that has big attachments is very
    slow because it builds decoded data string before
    just showing the button
      "Attached XXXX file: FILENAME.pdf (XXXkB)"
    We should build a data to be saved on the fly
    (i.e. after user's clicking).

Now the default value of rmail-enable-mime is t, and thus a
MIME message is properly decoded in RMAIL buffer
automatically.  One can still customize rmail-enable-mime to
nil, and type the command 'v' to view a decoded message in
the separete "*RMAIL*" buffer as before.

By the way, in the long run, I think it is better to utilize
gnus/mm*.el for rmail instead of further improving
rmailmm.el.

---
Kenichi Handa
handa@m17n.org