From: Anthony Towns <aj@erisian.com.au>
To: notmuch@notmuchmail.org
Subject: Re: Initial attempt at a "merge window" for notmuch
Date: Sat, 10 Apr 2010 05:18:35 +1000 [thread overview]
Message-ID: <s2o87b3a4191004091218o3e9ecfb7s7eb5defc313fb9f4@mail.gmail.com> (raw)
In-Reply-To: <87hbnktx1c.fsf@yoom.home.cworth.org>
On Sat, Apr 10, 2010 at 02:23, Carl Worth <cworth@cworth.org> wrote:
> 3. Ability to easily post search results to a web page.
Isn't that a job for "noneatall" [0] -- maybe it just needs the
ability to export to static pages, that can be rsync'ed somewhere?
[0] http://github.com/dme/noneatall
> 4. Fancy support for thread- vs. message-based search matches.
> We've talked about supporting a "muted" tag to make obnoxious
> threads disappear entirely. The idea we have there is a tag on a
> message, and then support for searches which compute set-theoretic
> operations based on sets of threads.
Is that an argument for tags on a thread rather than a message? With a
message mute tag, if you happen to delete the single message you've
tagged muted (maybe you killfile the sender of that message), suddenly
the whole thread reappears, which doesn't sound entirely desirable.
> 2. The ability to split a thread.
> I know I argued against this previously, but I know that "Plans for
> the 0.2 release" contains multiple independent topics, and I'd
> really like to be able to track those separately.
An MUA that did that well (or just effectively) would be massively fantastic.
Perhaps you could do it by associating threads with any message, so if
you've got an announcement A, with three followups, B, C and D, of
which C and D are interesting and novel subthreads, you could have
thread:00001 start at A and include everything, thread:00002 manually
pointed at C and include both its parents (A) and any children, but
not any siblings/cousins (B/D), and thread:00003 manually pointed at D
and behave likewise (including A, any responses to D, but not B, C or
any replies to B or C).
I don't know how you'd handle a mail, E, that came in that following
up to C though -- do you just report thread:00001 as having new mail,
or just thread:00002, or both of them? What if F comes in that
simultaneously replies to E and D? (Personally, I could probably be
comfortable with any of those behaviours)
> 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. That is, I can merge a
> feature and mark it "merged", but if someone replies later noticing
> a defect in the patch I merged, then I want that thread to reappear
> in my search results. But my current date restriction prevents
> that.
The above hypothetical features could let you do:
# create new threads at messages that are marked as postponed or merged
notmuch newthread -- not is:threadroot \( tag:merged or tag:postponed \)
# assume threads get the same tags as their "root" message, so that
# any messages in the above new threads will automagically match on
# threadtag:merged or threadtag:postponed. Thus:
notmuch search threadtag:merged 123456..123789
That's abusing subthreads as a poor man's set. Not really convinced
that's a good idea, but what the hey... Something to think about
maybe.
Cheers,
aj
--
Anthony Towns <aj@erisian.com.au>
next prev parent reply other threads:[~2010-04-09 19:18 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
2010-04-10 20:24 ` Michal Sojka
2010-04-10 22:57 ` Sandra Snan
2010-04-09 19:18 ` Anthony Towns [this message]
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=s2o87b3a4191004091218o3e9ecfb7s7eb5defc313fb9f4@mail.gmail.com \
--to=aj@erisian.com.au \
--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).