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.)