Re: RMAIL, MIME-related bug

[Kenichi Handa]

Juri Linkov <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.

---
Ken'ichi HANDA
address@hidden