Re: Rmail-mbox branch

[Stephen J. Turnbull]

Richard M. Stallman writes:
 > Stephen Turnbull wrote:

 >     Other MIME media-types can't be saved in decoded format, since
 >     that is going to be an Emacs internal data-type (consider
 >     image/png).
 > 
 > I don't follow you.

Media types other than "text" are attachments.  They can be displayed
by Emacs in many cases (eg, images, some XML files).  However, the
decoded format generally has no meaning as mbox contents; it's an
internal Emacs object with no defined serialization into ASCII.

Of course Rmail can simply ignore those attachments, and leave them
as-is in the mbox.  But Rmail will still need to know about MIME
multipart structures to edit any message containing them safely.
Similarly for any message containing non-ASCII text (at minimum it
would need to manipulate Content-Type headers).

 >      > I am not sure.  If it isn't valid as an mbox file, perhaps
 >      > it is true that Rmail/mbox needs to do this decoding
 >      > each time it displays the message, rather than just once
 >      > (as some have claimed before).

The kind of thing that Emacs will display is typically not going to be
a valid RFC 2822 message, and an mbox is simply a sequence of RFC 2822
messages (with empty line separators between messages, and a From line
prepended to each message, and possibly other minor variations
according to which MTA is writing, or which MUA is reading, the file).
Therefore, it is true that Rmail/mbox needs to be prepared to do
decoding each time it displays a message.

The alternative would be to simply declare that Rmail/mbox will *only*
handle multipart and text/plain media, and ignore all the rest.  But
that seems a shame when Emacs is quite capable of handling a wide
variety of media types, including text/html, text/rich-text, image,
audio, and even video (at least with the help of external players).