Initial attempt at a "merge window" for notmuch

[Mark Anderson]

On Fri, 9 Apr 2010 11:29:20 -0500, Carl Worth <cworth at cworth.org> wrote:
> On Fri, 09 Apr 2010 09:23:27 -0700, Carl Worth <cworth at cworth.org> wrote:
> >      For my merge window, I also want something that can't be obtained
> >      today. I want to see all threads that contain at least one message
> >      that matches my date range and at least one message that doesn't
> >      have the "merged" or "postponed" tag.
> ...
> >      I'm not sure how to best provide the ability to express the result
> >      I want here.
> 
> Of course, it's the same set-theoretic operation I described earlier. I
> want the set of threads having messages matching:
> 
> 	tag:notmuch and <date-range>
> 
> intersected with the set of threads having messages matching:
> 
> 	tag:notmuch and not ("merged" or "postponed")
> 
> So I've got uses cases for set-difference and intersection already. Now
> we just need some search syntax to express that.
> 

Can we just start grouping with a set:( ) or { } on the command line?
I'm guessing the parentheses are slightly easier.

   set:( tag:notmuch and <date-range> ) 
     isect 
   set:( tag:notmuch and not (tag:merged or tag:postponed) )

Isn't that close to what you're asking for?

It seems easy enough, and making the set:( explicit keeps you from
inventing a new quoting syntax if you tried to say 

  set:"tag:notmuch and <date-range>" 

then users get to play shell-quote-mambo to actually use this outside of
a client if they want (or think they want) quotes used in their search.

You can reuse the "and" and "or" term for set math, unless you are
averse to overloading, then isect, union are explicit enough about the
terms that you could infer the "set:" term for searches:

    tag:notmuch and <date-range> isect not ( tag:postponed or tag:merged ) 

But at the cost of introducing a new order of ops hierarchy.  I'm not
sure if you want to go there either.

Just thinking about completeness, I wonder if there are some searches
for threads that aren't currently available.

You could introduce a search modifier that would allow you to treat a
tag on a message in a thread as a tag on the entire thread, so that if
you have tag:mute on on message and tag:merged on another message in the
same thread, currently that does match:

  tag:merged and not tag:mute

But maybe you wanted only the THREADS instead of THREAD CONTAINS
searching.

I guess we're hampered by the fact that a thread object isn't a separate
object from the messages which comprise it's conversation, so we can't
look at the tags on a thread separately from the tags on messages in the
thread.  And maybe we don't want to.

Actually, this is where we differ slightly from gmail.  They have tags
on threads, and unread tags on messages.

I don't know that there's value in distinguishing between tags on a
thread and tags on a message in a thread when there isn't an object in
the mailstore that actually corresponds to a thread.

Hmmm, this isn't clear enough, so I'll just stop the rambling, but let
it stand.

-Mark

P.S. Sometimes I write a long note and don't get to the last sentence
for an hour or two.  I can be funny that way.