[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RMAIL, MIME-related bug

From: Kenichi Handa
Subject: Re: RMAIL, MIME-related bug
Date: Mon, 20 Oct 2003 13:18:56 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]