Re: Rmail-mbox branch

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> >     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).


        Stefan