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).
> I am still lost. You seem to allude to some difference between
text/plain and text/html which I am not aware of.
It's the same difference as between text/plain and any of the other
media types mentioned: you will cannot preserve all the information in
a text/html part while saving it in mbox format.
Rmail/mbox must be prepared to decode a message each time it is
presented.
I think that we are saying that the Rmail/mbox message presentation
buffer should decode as much of the MIME pieces as it can. The task
here is to make the Rmail/mime contributions a first class part of
Rmail. The developer with the initials "as" started that ball rolling
with (p/r)mailmm.el which is apparently based on Alexander Pohoyda's
work. This is the direction I plan to take. Comments?
I think that Pmail's MIME support should first limit itself to the small
subset supported by Rmail. Afterwards, it'd probably be good to try and
make it use Gnus's code (which IIUC is also used y MH-E, so you may
want to talk to the MH-E guy(s) to figure out how that worked).
BTW, as for how to handle the issue of "the current buffer is the mbox
file buffer but I want to display something else in it", you may want to
use the new buffer-swap-text primitive (currently only used in
tar-mode where the same problem appears).