Initial attempt at a "merge window" for notmuch

[Anthony Towns]

On Sat, Apr 10, 2010 at 02:23, Carl Worth <cworth at 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 at erisian.com.au>