From: Pieter Praet <pieter@praet.org>
To: Austin Clements <amdragon@MIT.EDU>
Subject: Re: [PROTO] possible solution for "Race condition for '*' command"
In-Reply-To: <e8c5fbf4-4dfa-461a-8f5c-6c696291a270@email.android.com>
References: <20110703171743.GL15901@mit.edu>
	<1309762318-4530-1-git-send-email-pieter@praet.org>
	<e8c5fbf4-4dfa-461a-8f5c-6c696291a270@email.android.com>
User-Agent: Notmuch/0.5-329-g1bb6068 (http://notmuchmail.org) Emacs/23.1.50.1
	(x86_64-pc-linux-gnu)
Date: Mon, 04 Jul 2011 20:48:12 +0200
Message-ID: <87sjqldgr7.fsf@praet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Notmuch Mail <notmuch@notmuchmail.org>
Precedence: list

On Mon, 04 Jul 2011 13:56:26 -0400, Austin Clements <amdragon@MIT.EDU> wrote:
Non-text part: multipart/alternative

> Ah, this is subtler than I thought. You're right that, for the '*'
> command, you want only the matched ID's. Tagging a region, however,
> operates on entire threads. I think it's important to retain this
> behavior because threads are what the user sees and selects in the
> search buffer (*, on the other hand, doesn't have a strong visual
> analogue).

Duly noted.

> (This also means * is not, in fact, equivalent to expanding the region
> the the entire buffer and then tagging the region.)

In fact it *is* but we'd be fetching the `matched-msgids' property
rather than the `thread-id' property, for each line in region.

> I should probably emit two lists per thread: one of matched IDs and
> one of unmatched IDs. Tagging a region can then operate on the
> concatenation of these, while * can operate only on the matched
> lists. This should be easy to do. I'll send an updated patch when I'm
> back at a computer.

The matched MsgIds will be sufficient, as we'll want to operate on
either the matched messages or the entire thread (for which the
`thread-id' property is already present).

Can't think of a use case for non-matched messages right now,
but if required, we'll just use `set-exclusive-or'.

> -- 
> Sent from my Android. Please excuse my brevity.

Tip: K-9 Mail [1], apart from being much better than the stock email client,
     supports bottom-posting :)

> Pieter Praet <pieter@praet.org> wrote:
> 
> Thanks Austin!
> 
> Unfortunately, your patch causes *all* Message-Id's in the thread to be
> appended, as opposed to only the ones matching the query:
> 
> #+BEGIN_EXAMPLE
> $ notmuch search tag:inbox AND from:amdragon@mit.edu
> thread:0000000000002777 Yest. 19:17 [1/3] Austin Clements| Pieter Praet;
> [PATCH 2/2] [RFC] possible solution for "Race condition for '*' command"
> (inbox replied sent to-me x/notmuch)
> id:"CAH-f9WticM4EN8F1_ik_-mcBcBtrXwSpO+Drbtp7=UN7McECrg@mail.gmail.com"
> or id:"87zkkwydag.fsf@praet.org" or id:"20110703171743.GL15901@mit.edu"
> #+END_EXAMPLE
> 
> As you can see, according to matched/total ("[1/3]") only a single
> message matches the query, yet all 3 MsgId's are returned.
> 
> If this were to be corrected (probably a trivial change, but I'm pretty
> much oblivious as to the what and where of it), the following patch
> series should work as intended.
> 
> The "--stdin" option works as expected (and ARG_MAX is indeed a very
> valid concern with this particular use case), but I haven't yet gotten
> around to making use of it from the Emacs UI as this would require some
> screwing around with `notmuch-tag' and `notmuch-call-notmuch-process',
> and it's still pretty early I-).
> 
> Peace
> 
> -- 
> Pieter
> 
Non-text part: text/html


Peace

-- 
Pieter

[1] http://code.google.com/p/k9mail/