Org-mode support
On Sun, 13 Feb 2011 19:25:05 +, Darren McGuicken wrote: > On Mon, 07 Feb 2011 22:22:17 +0100, Matthieu Lemerre wrote: > > I have written the org-mode support for notmuch a while ago. It allows > > to open links to notmuch from org-mode and create org-mode link from > > notmuch buffers. > > Excellent, thanks for this, I'll check it out - how does this compare to > the org support for something like gnus? I don't know exactly how org-mode supports gnus, but I think pretty much the same... Basically what it allows is: 1. When calling org-store-link (or org-capture) from a notmuch-message or notmuch-search window, store a link to this buffer. 2. When opening a link in org-mode, if the link is a notmuch link, open the corresponding notmuch buffer. I use this to empty my inbox and quickly store todo items to my TODO list/gtd file along the way. I believe that further org/notmuch integration could be beneficial, and this represents a first step.
Org-mode support
On Mon, 07 Feb 2011 22:22:17 +0100, Matthieu Lemerre wrote: > I have written the org-mode support for notmuch a while ago. It allows > to open links to notmuch from org-mode and create org-mode link from > notmuch buffers. Excellent, thanks for this, I'll check it out - how does this compare to the org support for something like gnus? -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110213/4f873f2d/attachment.pgp>
About the json output and the number of results shown.
On Sat, Jan 29, 2011 at 07:40, Carl Worth wrote: > One idea I've had for this is to change the output (perhaps with a > command-line option) to avoid emitting the outer array. That is, the > results would instead be a series of independent JSON objects rather > than a single JSON object. That should let the application treat things > quickly by simply calling the JSON parser for each complete > object. It might be useful to model this on the Twitter streaming API, which just delivers a lot of JSON + '\r\n' (large objects straddle http chunks). > (Though, here, the application would likely want a cheap way to > know when the input represented a complete object.) > Is that necessary? You're definitely going to get a \r\n or an EOF at some point. :-) - Jeff -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110213/7c1ea1ee/attachment.html>
[PATCH 0/5] Fetch all message metadata in a single pass
I've rebased this against current master and fixed a few merge conflicts. The rebased patches are on the eager-metadata-v3 branch of http://awakening.csail.mit.edu/git/notmuch.git On Thu, Dec 9, 2010 at 3:59 PM, Austin Clements wrote: > This is the second of the two optimizations I described a while ago, > and brings my inbox search down to 1.811 seconds, 2.5X faster than it > was originally. > > This optimization is based on the observation that Xapian decompresses > a document's term list every time you iterate over it. ?As a result, > notmuch can decompress the beginning of a single term list quite a few > times. ?This patch series combines all of this into a single pass that > is only slightly more expensive than fetching one metadata field used > to be, but offers a huge win in the common case where a message object > is used for multiple metadata fields. > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch >
