MIME-Version: 1.0
Sender: amdragon@gmail.com
In-Reply-To: <87r56brtxt.fsf@praet.org>
References: <8739itagad.fsf@yoom.home.cworth.org>
	<1309450108-2793-1-git-send-email-pieter@praet.org>
	<1309450108-2793-2-git-send-email-pieter@praet.org>
	<87r56brtxt.fsf@praet.org>
Date: Fri, 1 Jul 2011 10:55:13 -0400
Message-ID:
 <CAH-f9WstN909tsDepsmPUvfgudkv0mHTzsvuRAeq0B+-ywtrrw@mail.gmail.com>
Subject: Re: [PATCH 2/2] [RFC] possible solution for "Race condition for '*'
	command"
From: Austin Clements <amdragon@mit.edu>
To: Pieter Praet <pieter@praet.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
Precedence: list

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:
> =A0- run "notmuch-command search" with the "--output=3Dmessages" option
> =A0 =A0instead of a plain search,
> =A0- maintain a buffer-local var with a list of returned Message-Id's,
> =A0- ...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.