Re: improve rmail's MIME handling

["Stephen J. Turnbull" <stephen@xemacs.org>]

Richard Stallman writes:

 > It's ok to enable mime handling in Rmail by default if it is done in a
 > convenient way.  A convenient way is one that helps without forcing
 > itself on you, without switching buffers unless you request it.

I hope it's OK to create a presentation buffer for the current
message.

 > It has to let you read textual attachments in the message
 > buffer itself.

For text/plain and text/richtext, VM does this by default without
problem (modulo doing it in a presentation buffer rather than in the
original message buffer).

This may be hard for text/html, at least if you get mail from people
using non-Emacs MUAs.  There's good reason why people push HTML mail
out to specialized browsers.

 > It should not try to decode the non-textual attachments until you ask
 > for specific ones.

By popular demand, VM switched from that approach to decoding images
by default.  Of course this can be switched off, and the list of MIME
media types to automatically display is configurable.  The point: if
RMail is going to continue to be the preferred MUA of a tiny minority,
switched off by default is probably OK.  But if the intent is to make
Rmail attractive to average users, you'd better poll users on this.

 > I would suggest making the non-textual attachments invisible, showing
 > only their header lines.

It's better to have a single summary line.  The header lines of body
parts are often complex and uninformative (eg, the media subtypes and
content-type parameters rarely matter except to the decoding
programs).  Users want to know media type, file name, and content
description, which should easily be abstracted into 10 + 20 + 40 = 70
columns in most cases.

More important is checks that file name extensions match media type,
and that magic numbers match media type (usually the underlying
library gets that right, but sometimes not, and Emacs does implement
some types in Lisp).  Those are not easy for users to do.

 > If you want to see the contents of one, you type v on it.

Yep, that's the VM model, except that the default action (often but by
no means always = view) is activated by RET, and $ is a prefix key
that introduces bindings for alternative actions (including view, save
(which may have multiple variants, eg, for message/rfc822 parts or for
application/* parts with multiple decoder implementations), and
sometimes others).