MIME-version: 1.0
Content-type: multipart/alternative;
	boundary="Boundary_(ID_9a3eFww91i+V0AqUg063OA)"
To: David Bremner <david@tethera.net>
From: Trevor Jim <tjim@mac.com>
Subject: Re: nevermore
Date: Wed, 16 Jul 2014 14:51:24 +0000 (GMT)
Message-id: <74f07268-8018-4790-885c-27f0dfb6733c@me.com>
Cc: notmuch@notmuchmail.org
Precedence: list


--Boundary_(ID_9a3eFww91i+V0AqUg063OA)
Content-type: text/plain; charset=utf-8; format=flowed
Content-transfer-encoding: quoted-printable

If you would like to incorporate things into the main branch, that would b=
e great. Here's what I think the status is:=0A=0AThe asynchronous mail add=
ress harvesting works pretty well. Much better than having to install pyth=
on etc. It would be better to also update the addresses when sending mail.=
=0A=0AI imagine many people want to use something other than company-mode,=
 though. Probably needs testing for other completion systems.=0A=0AThe inc=
remental search works well for me, but I think it needs testing on larger =
maildirs. Notmuch as it exists today does not seem to have incremental sea=
rch in mind. For example, I have to kill and start a new process each time=
 the search term changes (potentially on each keystroke).=0A=0AMy async pa=
rsing is noticeably faster than notmuch.el, so you might want to incorpora=
te some of its ideas, regardless of whether you take incremental search.=0A=
=0AOne complication of the incremental search code is that I like to query=
 based on messages rather than threads. Both are actually useful, but I'm =
happier with messages. (For one thing, it should be much faster.) Notmuch,=
 of course, is thread-focused.=0A=0AFor message-based search, --output=3Ds=
ummary is not appropriate, even if the query is a message-id; the result i=
ncludes, for example, tags that appear only in other messages in the threa=
d. So I have been forced to use notmuch show --body=3Dfalse instead. This =
precludes other useful options of notmuch search, e.g., --sort. Anyway, th=
e incremental search code has some complications for this. I'd love for no=
tmuch search to have a --output=3Dmessage-summary option to avoid this.=0A=
=0A-Trevor=0A=EF=BB=BF=0A=

--Boundary_(ID_9a3eFww91i+V0AqUg063OA)
Content-type: multipart/related;
 boundary="Boundary_(ID_bMCoUUu9DlyD+gmZQEu3fg)"; type="text/html"


--Boundary_(ID_bMCoUUu9DlyD+gmZQEu3fg)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable

<html><body><div>If you would like to incorporate things into the main branch, that wo=
uld be great. Here's what I think the status is:<br><br>The asynchronous m=
ail address harvesting works pretty well. Much better than having to insta=
ll python etc. It would be better to also update the addresses when sendin=
g mail.<br><br>I imagine many people want to use something other than comp=
any-mode, though. Probably needs testing for other completion systems.<br>=
<br>The incremental search works well for me, but I think it needs testing=
 on larger maildirs. Notmuch as it exists today does not seem to have incr=
emental search in mind. For example, I have to kill and start a new proces=
s each time the search term changes (potentially on each keystroke).<br><b=
r>My async parsing is noticeably faster than notmuch.el, so you might want=
 to incorporate some of its ideas, regardless of whether you take incremen=
tal search.<br><br>One complication of the incremental search code is that=
 I like to query based on messages rather than threads. Both are actually =
useful, but I'm happier with messages. (For one thing, it should be much f=
aster.) Notmuch, of course, is thread-focused.<br><br>For message-based se=
arch, --output=3Dsummary is not appropriate, even if the query is a messag=
e-id; the result includes, for example, tags that appear only in other mes=
sages in the thread. So I have been forced to use notmuch show --body=3Dfa=
lse instead. This precludes other useful options of notmuch search, e.g., =
--sort. Anyway, the incremental search code has some complications for thi=
s. I'd love for notmuch search to have a --output=3Dmessage-summary option=
 to avoid this.<br><br>-Trevor<br><br></div></body></html>=

--Boundary_(ID_bMCoUUu9DlyD+gmZQEu3fg)--

--Boundary_(ID_9a3eFww91i+V0AqUg063OA)--