--- /dev/null
+Return-Path: <tjim@mac.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id E514E431FC3\r
+ for <notmuch@notmuchmail.org>; Wed, 16 Jul 2014 07:51:37 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.297\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5\r
+ tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,\r
+ MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id MkfLykdK9nhK for <notmuch@notmuchmail.org>;\r
+ Wed, 16 Jul 2014 07:51:31 -0700 (PDT)\r
+Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com\r
+ [17.172.220.236]) (using TLSv1 with cipher RC4-MD5 (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 9E895431FBD\r
+ for <notmuch@notmuchmail.org>; Wed, 16 Jul 2014 07:51:31 -0700 (PDT)\r
+MIME-version: 1.0\r
+Content-type: multipart/alternative;\r
+ boundary="Boundary_(ID_9a3eFww91i+V0AqUg063OA)"\r
+Received: from st11p02mm-spool002.mac.com ([17.172.220.247])\r
+ by st11p02mm-asmtp001.mac.com\r
+ (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit\r
+ (built Jun\r
+ 6 2014)) with ESMTP id <0N8T00GJP7XONS80@st11p02mm-asmtp001.mac.com>\r
+ for notmuch@notmuchmail.org; Wed, 16 Jul 2014 14:51:24 +0000 (GMT)\r
+X-Proofpoint-Virus-Version: vendor=fsecure\r
+ engine=2.50.10432:5.12.52,1.0.14,0.0.0000\r
+ definitions=2014-07-16_05:2014-07-16, 2014-07-16,\r
+ 1970-01-01 signatures=0\r
+X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0\r
+ suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\r
+ adjust=0\r
+ reason=mlx scancount=1 engine=7.0.1-1402240000\r
+ definitions=main-1407160173\r
+Received: from localhost ([17.172.220.163]) by st11p02mm-spool002.mac.com\r
+ (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit\r
+ (built Aug\r
+ 22 2013)) with ESMTP id <0N8T00DCU7XOZF00@st11p02mm-spool002.mac.com>;\r
+ Wed, 16 Jul 2014 14:51:24 +0000 (GMT)\r
+To: David Bremner <david@tethera.net>\r
+From: Trevor Jim <tjim@mac.com>\r
+Subject: Re: nevermore\r
+Date: Wed, 16 Jul 2014 14:51:24 +0000 (GMT)\r
+X-Mailer: iCloud MailClient14D29 MailServer14E24.16380\r
+X-Originating-IP: [128.112.139.195]\r
+Message-id: <74f07268-8018-4790-885c-27f0dfb6733c@me.com>\r
+X-Mailman-Approved-At: Sun, 20 Jul 2014 13:32:26 -0700\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 16 Jul 2014 14:51:38 -0000\r
+\r
+\r
+--Boundary_(ID_9a3eFww91i+V0AqUg063OA)\r
+Content-type: text/plain; charset=utf-8; format=flowed\r
+Content-transfer-encoding: quoted-printable\r
+\r
+If you would like to incorporate things into the main branch, that would b=\r
+e great. Here's what I think the status is:=0A=0AThe asynchronous mail add=\r
+ress harvesting works pretty well. Much better than having to install pyth=\r
+on etc. It would be better to also update the addresses when sending mail.=\r
+=0A=0AI imagine many people want to use something other than company-mode,=\r
+ though. Probably needs testing for other completion systems.=0A=0AThe inc=\r
+remental search works well for me, but I think it needs testing on larger =\r
+maildirs. Notmuch as it exists today does not seem to have incremental sea=\r
+rch in mind. For example, I have to kill and start a new process each time=\r
+ the search term changes (potentially on each keystroke).=0A=0AMy async pa=\r
+rsing is noticeably faster than notmuch.el, so you might want to incorpora=\r
+te some of its ideas, regardless of whether you take incremental search.=0A=\r
+=0AOne complication of the incremental search code is that I like to query=\r
+ based on messages rather than threads. Both are actually useful, but I'm =\r
+happier with messages. (For one thing, it should be much faster.) Notmuch,=\r
+ of course, is thread-focused.=0A=0AFor message-based search, --output=3Ds=\r
+ummary is not appropriate, even if the query is a message-id; the result i=\r
+ncludes, for example, tags that appear only in other messages in the threa=\r
+d. So I have been forced to use notmuch show --body=3Dfalse instead. This =\r
+precludes other useful options of notmuch search, e.g., --sort. Anyway, th=\r
+e incremental search code has some complications for this. I'd love for no=\r
+tmuch search to have a --output=3Dmessage-summary option to avoid this.=0A=\r
+=0A-Trevor=0A=EF=BB=BF=0A=\r
+\r
+--Boundary_(ID_9a3eFww91i+V0AqUg063OA)\r
+Content-type: multipart/related;\r
+ boundary="Boundary_(ID_bMCoUUu9DlyD+gmZQEu3fg)"; type="text/html"\r
+\r
+\r
+--Boundary_(ID_bMCoUUu9DlyD+gmZQEu3fg)\r
+Content-type: text/html; CHARSET=US-ASCII\r
+Content-transfer-encoding: quoted-printable\r
+\r
+<html><body><div>If you would like to incorporate things into the main branch, that wo=\r
+uld be great. Here's what I think the status is:<br><br>The asynchronous m=\r
+ail address harvesting works pretty well. Much better than having to insta=\r
+ll python etc. It would be better to also update the addresses when sendin=\r
+g mail.<br><br>I imagine many people want to use something other than comp=\r
+any-mode, though. Probably needs testing for other completion systems.<br>=\r
+<br>The incremental search works well for me, but I think it needs testing=\r
+ on larger maildirs. Notmuch as it exists today does not seem to have incr=\r
+emental search in mind. For example, I have to kill and start a new proces=\r
+s each time the search term changes (potentially on each keystroke).<br><b=\r
+r>My async parsing is noticeably faster than notmuch.el, so you might want=\r
+ to incorporate some of its ideas, regardless of whether you take incremen=\r
+tal search.<br><br>One complication of the incremental search code is that=\r
+ I like to query based on messages rather than threads. Both are actually =\r
+useful, but I'm happier with messages. (For one thing, it should be much f=\r
+aster.) Notmuch, of course, is thread-focused.<br><br>For message-based se=\r
+arch, --output=3Dsummary is not appropriate, even if the query is a messag=\r
+e-id; the result includes, for example, tags that appear only in other mes=\r
+sages in the thread. So I have been forced to use notmuch show --body=3Dfa=\r
+lse instead. This precludes other useful options of notmuch search, e.g., =\r
+--sort. Anyway, the incremental search code has some complications for thi=\r
+s. I'd love for notmuch search to have a --output=3Dmessage-summary option=\r
+ to avoid this.<br><br>-Trevor<br><br></div></body></html>=\r
+\r
+--Boundary_(ID_bMCoUUu9DlyD+gmZQEu3fg)--\r
+\r
+--Boundary_(ID_9a3eFww91i+V0AqUg063OA)--\r
projects / notmuch-archives.git / commitdiff