Re: [PATCH 2/2] [RFC] possible solution for "Race condition for '*' command"

[Pieter Praet <pieter@praet.org>]

On Fri, 1 Jul 2011 12:37:11 -0400, Austin Clements <amdragon@mit.edu> wrote:
Non-text part: multipart/alternative
> On Jul 1, 2011 10:55 AM, "Austin Clements" <amdragon@mit.edu> wrote:
> >
> > On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet <pieter@praet.org> wrote:
> > > Ok, even though my very first reply [1] may have created the impression
> > > that I understood the issue, I clearly didn't...
> > >
> > > The test [2] needs a more applicable commit message, and the subsequent
> > > patch [3] points more or less in the right direction, but the Message-Id
> > > list should be local to the *search buffer* rather than to the
> > > `notmuch-search-operate-all' function.
> > >
> > > `notmuch-search' could:
> > >  - run "notmuch-command search" with the "--output=messages" option
> > >    instead of a plain search,
> > >  - maintain a buffer-local var with a list of returned Message-Id's,
> > >  - ...and populate the buffer based on that list.
> > >
> > > As such we'd have -for each individual search buffer- a canonical list
> > > of Message-Id's (i.e. messages which actually *match* the query AND are
> > > currently visible in the search buffer), to be used by
> > > `notmuch-search-operate-all' et al.
> > >
> > >
> > > Peace
> > >
> > > --
> > > Pieter
> > >
> > > [1] id:"87fwmuxxgd.fsf@praet.org"
> > > [2] id:"1309450108-2793-2-git-send-email-pieter@praet.org"
> > > [3] id:"1309450108-2793-1-git-send-email-pieter@praet.org"
> >
> > Ideally, this wouldn't be per-buffer, but per *line*.  This race
> > equally affects adding and removing tags from individual results,
> > since that's done using a thread: query, whose results could have
> > changed since the original search.
> >
> > This almost certainly requires support from the notmuch core.  The
> > good news is that the library already provides this information, so
> > there will be virtually no performance hit for outputting it.
> 
> Actually, with a smidgeon of library support, you could even use document
> IDs for this, rather than message IDs, which would make the tagging
> operations (even '*') no more expensive than they are now.  (Of course, it
> would be good to know just how much overhead going through message IDs
> actually introduces.)
Non-text part: text/html


That would be awesome!

Though I'd rather leave the plumbing to someone sufficiently capable,
so, if leaving libnotmuch hacking out of the equation, how would one go
about doing this?

I (ignorantly) assume we'd get `notmuch-search-process-filter'
to append each line with an invisible field containing a list
of matching Message-Id's, presumably obtained via
`notmuch_thread_get_matched_messages' (@ lib/thread.cc) ?


Peace

-- 
Pieter