1 Return-Path: <cworth@cworth.org>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id A06D7431FBC;
\r
6 Sun, 22 Nov 2009 20:14:40 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
8 Received: from olra.theworths.org ([127.0.0.1])
\r
9 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
10 with ESMTP id tnFU+TtGvH3U; Sun, 22 Nov 2009 20:14:39 -0800 (PST)
\r
11 Received: from cworth.org (localhost [127.0.0.1])
\r
12 by olra.theworths.org (Postfix) with ESMTP id 3E48E431FAE;
\r
13 Sun, 22 Nov 2009 20:14:39 -0800 (PST)
\r
14 From: Carl Worth <cworth@cworth.org>
\r
15 To: Jed Brown <jed@59A2.org>, notmuch@notmuchmail.org
\r
16 In-Reply-To: <1258920736-14205-1-git-send-email-jed@59A2.org>
\r
17 References: <1258920736-14205-1-git-send-email-jed@59A2.org>
\r
18 Date: Mon, 23 Nov 2009 05:14:25 +0100
\r
19 Message-ID: <87ocmtg9ni.fsf@yoom.home.cworth.org>
\r
21 Content-Type: text/plain; charset=us-ascii
\r
22 Subject: Re: [notmuch] [PATCH] New function notmuch-search-operate-all:
\r
23 operate on all messages in the current query.
\r
24 X-BeenThere: notmuch@notmuchmail.org
\r
25 X-Mailman-Version: 2.1.12
\r
27 List-Id: "Use and development of the notmuch mail system."
\r
28 <notmuch.notmuchmail.org>
\r
29 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
30 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
31 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
32 List-Post: <mailto:notmuch@notmuchmail.org>
\r
33 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
34 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
35 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
36 X-List-Received-Date: Mon, 23 Nov 2009 04:14:40 -0000
\r
38 On Sun, 22 Nov 2009 21:12:16 +0100, Jed Brown <jed@59A2.org> wrote:
\r
39 > It is often convenient to change tags on several messages at once. This
\r
40 > function applies any number of tag whitespace-delimited tag
\r
41 > modifications to all messages matching the current query.
\r
43 > I have bound this to `*'.
\r
47 I've been wanting this feature for a while, and I think you just
\r
48 improved on my idea in at least two ways.
\r
50 First I was imagining that the '*' would be a prefix command, but I like
\r
51 it just prompting for the '+' or '-' as part of the argument. That's no
\r
52 more typing and allows for doing multiple tags at once.
\r
54 Second, I like that you just used the search string again, (as opposed
\r
55 to just walking through the buffer looking at thread IDs). That seems
\r
58 On second thought, however, using the search string is problematic for
\r
59 at least two reasons:
\r
61 First, this creates a race condition in that the user will rightly
\r
62 expect to only be adding/removing tags from the visible results. But if
\r
63 new mail has been incorporated between creating the current view and
\r
64 running '*' then threads could be tagged that were never seen and that
\r
65 could be problematic.
\r
67 Second, since we're in the search view which shows threads, we should
\r
68 really be operating on threads. But this tag command won't work like the
\r
69 '+' and '-' commands in this buffer. Those commands will add/remove a
\r
70 tag to/from every message in the thread[*]. The new '*' command, however
\r
71 will only be changing tags on messages that match the query.
\r
73 So I think we should fix both of these issues by looping over each line
\r
74 of the buffer and calling (notmuch-search-add-tag) or
\r
75 (notmuch-search-remove-tag).
\r
81 [*] These existing '+' and '-' operations (as well as 'a') that act on
\r
82 the entire thread also have a race condition. They are potentially
\r
83 modifying more messages than the original search matched. This is often
\r
84 harmless, (you aren't even *seeing* the messages so how can you complain
\r
85 if more get modified than were there when you did the search.). But it
\r
86 can actually be fatal:
\r
88 Imagine I sent a message to the list, and then in the search view I see
\r
89 that message appear and it has [1/1] indicating it's the only message in
\r
90 the thread. I might archive this "knowing" I've read the message
\r
91 already, but this could actually archive a reply as well that arrived
\r
92 between when I did the search and when I archived.
\r
94 So that's a bug that we really should fix. [And noted that archiving an
\r
95 entire thread from the notmuch-show-mode does not have this bug since it
\r
96 acts only on the explicit messages that are presented.] One option to
\r
97 fix this would be for "notmuch search" to list all the message IDs that
\r
98 matched in place of the thread ID (for notmuch-search-mode to hide away
\r
99 like it does with the thread ID currently). But that seems like it might
\r
100 get problematic with some hugely long threads.
\r
102 Anyway, I'm interested in ideas for what we could do here.
\r
104 Oh, here's one: We could add something like "notmuch tag --expecting=
\r
105 1/23 <search-terms>" that would not do the tag unless the search string
\r
106 matched 1 message out of 23 total messages in the thread. Then we could
\r
107 give a warning to the user. That works for the single-thread case, but
\r
108 the warning would be harder for the user to deal with in the '*'
\r
109 case. Or maybe not---the emacs function could just stop on the first
\r
110 line with the error and then the user would see what's going on.
\r
112 And we could take a prefix argument to ignore such errors.
\r
114 Any other thoughts on this?
\r
projects / notmuch-archives.git / blob