From: Mark Anderson <MarkR.Anderson@amd.com>
To: Carl Worth <cworth@cworth.org>,
"notmuch\@notmuchmail.org" <notmuch@notmuchmail.org>
Subject: Re: Initial attempt at a "merge window" for notmuch
Date: Fri, 9 Apr 2010 13:43:45 -0600 [thread overview]
Message-ID: <3wdpr282yz2.fsf@testarossa.amd.com> (raw)
In-Reply-To: <87fx34twrj.fsf@yoom.home.cworth.org>
On Fri, 9 Apr 2010 11:29:20 -0500, Carl Worth <cworth@cworth.org> wrote:
> On Fri, 09 Apr 2010 09:23:27 -0700, Carl Worth <cworth@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.
next prev parent reply other threads:[~2010-04-09 19:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-09 16:23 Initial attempt at a "merge window" for notmuch Carl Worth
2010-04-09 16:29 ` Carl Worth
2010-04-09 19:43 ` Mark Anderson [this message]
2010-04-10 20:24 ` Michal Sojka
2010-04-10 22:57 ` Sandra Snan
2010-04-09 19:18 ` Anthony Towns
2010-04-10 13:55 ` Sebastian Spaeth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3wdpr282yz2.fsf@testarossa.amd.com \
--to=markr.anderson@amd.com \
--cc=cworth@cworth.org \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).