Re: RMAIL, MIME-related bug

[Juri Linkov]

Stefan Monnier <address@hidden> writes:
> Why do people even consider doing any processing at that point?
> The processing should be done for display and nothing else, because any
> other option will make you lose information at some point and also forces
> you to have code to re-create the original format, whereas the "display-side
> processing" approach only needs to parse MIME but never needs to
> re-construct it.

I will not argue about the default mbox format (it's pretty obvious that
messages should be preserved in their original transferred format).
But I'll tell about functionality still missing in Emacs.

1. Often there is a need to grep the mail archive for some old message.
This is impossible if message is encoded in base64/quoted-printable.

2. Sometimes there is a need to make a bookmark to the message to be
able to quickly return to it later.  Hopeless.  Only one way to fetch
old message is to start MUA and browse through dozens of folders and
hundreds of messages in every folder.

I see one solution to these problems - to export entire mbox to the
file system, i.e. to save MIME parts to separate files, decode
base64/quoted-printable regions, convert the charset from Content-Type
line to Emacs encoding, add corresponding -*- coding: -*- line, and
save fully decoded message to a separate file.

Note that this don't contradict the decision to store messages in mbox
in their undecoded form.  The proposed solution duplicates the content
of messages in the decoded form.  Hard disks now so cheap that having
two copies of the same message is not a problem.  The decoded messages
could also be used as a cache to make displaying messages faster,
whereas undecoded messages will be available to resend forwards, where
no original information should be lost.  There should be some way to
correlate between them, i.e. to find corresponding decoded message
from undecoded one, and vice versa.

-- 
http://www.jurta.org/emacs/