From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: RMAIL, MIME-related bug Date: Fri, 17 Oct 2003 11:20:21 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200310170220.LAA29602@etlken.m17n.org> References: <200310121947.h9CJlhKH006102@oak.pohoyda.family> <6480-Thu16Oct2003192118+0200-eliz@elta.co.il> <200310161914.h9GJEYW0004195@beta.mvs.co.il> <87ekxczw0t.fsf@oak.pohoyda.family> <200310162221.h9GMLUvV000692@beta.mvs.co.il> <200310162348.h9GNmZm25160@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1066357445 823 80.91.224.253 (17 Oct 2003 02:24:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2003 02:24:05 +0000 (UTC) Cc: ehud@unix.mvs.co.il, emacs-devel@gnu.org, eliz@elta.co.il, alexander.pohoyda@gmx.net, monnier@IRO.UMontreal.CA Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Oct 17 04:24:02 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AAKHa-0008N5-00 for ; Fri, 17 Oct 2003 04:24:02 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AAKHY-0007RD-00 for ; Fri, 17 Oct 2003 04:24:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AAKF8-0002wo-Ey for emacs-devel@quimby.gnus.org; Thu, 16 Oct 2003 22:21:30 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AAKEr-0002wa-78 for emacs-devel@gnu.org; Thu, 16 Oct 2003 22:21:13 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AAKEL-0002qv-BL for emacs-devel@gnu.org; Thu, 16 Oct 2003 22:21:12 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AAKEK-0002q8-MI for emacs-devel@gnu.org; Thu, 16 Oct 2003 22:20:40 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/3.7W-20010518204228) with ESMTP id h9H2KMh13009; Fri, 17 Oct 2003 11:20:22 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6/3.7W-20010823150639) with ESMTP id h9H2KMs17208; Fri, 17 Oct 2003 11:20:22 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id LAA29602; Fri, 17 Oct 2003 11:20:21 +0900 (JST) Original-To: teirllm@dms.auburn.edu In-reply-to: <200310162348.h9GNmZm25160@raven.dms.auburn.edu> (message from Luc Teirlinck on Thu, 16 Oct 2003 18:48:35 -0500 (CDT)) 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) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17189 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17189 In article <200310162348.h9GNmZm25160@raven.dms.auburn.edu>, Luc Teirlinck 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 handa@m17n.org