On Tue, 14 Feb 2012 10:21:14 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
> Quoth Mark Walters on Feb 14 at 12:28 pm:
> > Finally, if notmuch-pick were able to do work asynchronously (as
> > notmuch-search does now) then I think all the speed concerns would go
> > away. However, I am not sure how to do incremental json parsing.
> 
> For JSON search, at least, I think we've concluded that it should put
> newlines at strategic places in the JSON output (and never anywhere
> else) so that it's easy for a consumer to know when it has a complete
> JSON object and hand it to the JSON parser.  E.g.,
> 
> [{"thread":"X", timestamp: 42, ...}
> ,{"thread":"Y", timestamp: 24, ...}
> ]
> 
> This "framed JSON" works really well for the flat output of search.
> It's obviously trickier to apply to show's hierarchical output.  But,
> perhaps this will inspire you.
> 
> (One possibility: we could rework show's output to be non-hierarchical
> and use the above framing; that is, it could be a sequence of message
> objects that each indicate which earlier message object they're a
> reply to, probably restricted to DFS order.)

Here is a (very early version) of an async notmuch-pick based on the
above idea. This is on top of the previous patch series. There are two
attached patches: the first is a very small patch to notmuch-show.c to
print newlines between threads (since this is sufficient framing for
notmuch-pick; obviously it does not help notmuch-show at all).

The second patch implements the async handling in notmuch-pick.el. This
is probably very inefficient, and doubtless has significant bugs, but it
seems to mostly work and does display the first page of results almost
immediately even on very large queries so I think this is the right way
to go.

I am mostly posting it so people can play with the functionality but
cleanups, bugfixes, bug reports etc are gratefully received!

Best wishes

Mark