Re: RMAIL, MIME-related bug

[Alexander Pohoyda]

Kenichi Handa <address@hidden> writes:

> > 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.
 
> This method is very similar to what I proposed in my
> previous mail.
> 
> Kenichi Handa <address@hidden> writes:
> > (1) Read RMAIL file without decoding into some hidden source
> >     buffer (unibyte).  It may be ok to process only
> >     Content-Transfer-Encoding.
> > (2) Prepare a view buffer.
> > (3) Insert the current message in the view buffer after decoding
> >     it. 
> > (4) A background process (run by idle timer?) decodes not
> >     yet decoded message into the view buffer (like
> >     jit-lock-stealth-fontify).
> 
> Mine doesn't save the view buffer in a file, yours does.

I like these ideas very much and I'll keep them in my mind.
Thank you very much!


-- 
Alexander Pohoyda <address@hidden>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44