From: Carl Worth <cworth@cworth.org>
To: Jed Brown <jed@59A2.org>, notmuch@notmuchmail.org
In-Reply-To: <1258920736-14205-1-git-send-email-jed@59A2.org>
References: <1258920736-14205-1-git-send-email-jed@59A2.org>
Date: Mon, 23 Nov 2009 05:14:25 +0100
Message-ID: <87ocmtg9ni.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [notmuch] [PATCH] New function notmuch-search-operate-all:
 operate on all messages in the current query.
Precedence: list

On Sun, 22 Nov 2009 21:12:16 +0100, Jed Brown <jed@59A2.org> wrote:
> It is often convenient to change tags on several messages at once.  This
> function applies any number of tag whitespace-delimited tag
> modifications to all messages matching the current query.
> 
> I have bound this to `*'.

Very nice, Jed!

I've been wanting this feature for a while, and I think you just
improved on my idea in at least two ways.

First I was imagining that the '*' would be a prefix command, but I like
it just prompting for the '+' or '-' as part of the argument. That's no
more typing and allows for doing multiple tags at once.

Second, I like that you just used the search string again, (as opposed
to just walking through the buffer looking at thread IDs). That seems
elegant.

On second thought, however, using the search string is problematic for
at least two reasons:

First, this creates a race condition in that the user will rightly
expect to only be adding/removing tags from the visible results. But if
new mail has been incorporated between creating the current view and
running '*' then threads could be tagged that were never seen and that
could be problematic.

Second, since we're in the search view which shows threads, we should
really be operating on threads. But this tag command won't work like the
'+' and '-' commands in this buffer. Those commands will add/remove a
tag to/from every message in the thread[*]. The new '*' command, however
will only be changing tags on messages that match the query.

So I think we should fix both of these issues by looping over each line
of the buffer and calling (notmuch-search-add-tag) or
(notmuch-search-remove-tag).

What do you think?

-Carl

[*] These existing '+' and '-' operations (as well as 'a') that act on
the entire thread also have a race condition. They are potentially
modifying more messages than the original search matched. This is often
harmless, (you aren't even *seeing* the messages so how can you complain
if more get modified than were there when you did the search.). But it
can actually be fatal:

Imagine I sent a message to the list, and then in the search view I see
that message appear and it has [1/1] indicating it's the only message in
the thread. I might archive this "knowing" I've read the message
already, but this could actually archive a reply as well that arrived
between when I did the search and when I archived.

So that's a bug that we really should fix. [And noted that archiving an
entire thread from the notmuch-show-mode does not have this bug since it
acts only on the explicit messages that are presented.] One option to
fix this would be for "notmuch search" to list all the message IDs that
matched in place of the thread ID (for notmuch-search-mode to hide away
like it does with the thread ID currently). But that seems like it might
get problematic with some hugely long threads.

Anyway, I'm interested in ideas for what we could do here.

Oh, here's one: We could add something like "notmuch tag --expecting=
1/23 <search-terms>" that would not do the tag unless the search string
matched 1 message out of 23 total messages in the thread. Then we could
give a warning to the user. That works for the single-thread case, but
the warning would be harder for the user to deal with in the '*'
case. Or maybe not---the emacs function could just stop on the first
line with the error and then the user would see what's going on.

And we could take a prefix argument to ignore such errors.

Any other thoughts on this?