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