emacs-devel
[Top][All Lists]
Advanced

[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: Fri, 17 Oct 2003 11:20:21 +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)

In article <address@hidden>, Luc Teirlinck <address@hidden> writes:
> Ehud Karni wrote:
>    I store email too, but still I say that only few are read more than
>    once. What summary navigation has to with it ?

> In RMAIL, with a summary buffer and an RMAIL buffer in another window,
> C-p and C-n in the summary buffer update the message shown in the
> RMAIL buffer.  The MIME decoding should be fast enough not to
> excessively slow down C-n and C-p in the summary buffer.  It should
> also be fast enough not to excessively slow down `n' and `p' in the
> RMAIL buffer itself, which I would guess to be pretty much equivalent
> (in that sense, "_summary_ navigation" is not the main problem,
> navigation _in whatever form_ is.)

One more point about efficiency is rmail-search and
rmail-search-backwards.  I can wait for a while just after I
type M-x rmail or g in RMAIL buffer.  But, I won't be able
to stand slowdown of those search operations.

I think this kind of method is ideal.

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

While decoding, keep such big embeded data as images and
*.tar.gz in the source buffer, and embed buttons or
something in the view buffer.  Ignoreable headers are as
well.  Then, although we have double buffers source and
view, the latter won't become that big because it contains
only text.

We don't have to decode spam-like messages (detected
somehow) correctly, instead just insert "Perhaps this
message is a spam" in the view buffer, and allow users to
click it if they really want to see a decoded message.

But, it seems that it is a faily complicated work to
implement such a mechanism.

---
Ken'ichi HANDA
address@hidden




reply via email to

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