--- /dev/null
+Return-Path: <five9a2@gmail.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 1340F431FC0\r
+ for <notmuch@notmuchmail.org>; Mon, 23 Nov 2009 05:06:52 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id S3H9nSoDYBcm for <notmuch@notmuchmail.org>;\r
+ Mon, 23 Nov 2009 05:06:51 -0800 (PST)\r
+Received: from mail-bw0-f224.google.com (mail-bw0-f224.google.com\r
+ [209.85.218.224])\r
+ by olra.theworths.org (Postfix) with ESMTP id D1E8B431FBC\r
+ for <notmuch@notmuchmail.org>; Mon, 23 Nov 2009 05:06:50 -0800 (PST)\r
+Received: by bwz24 with SMTP id 24so3879783bwz.30\r
+ for <notmuch@notmuchmail.org>; Mon, 23 Nov 2009 05:06:49 -0800 (PST)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
+ h=domainkey-signature:received:received:sender:from:to:subject\r
+ :in-reply-to:references:date:message-id:mime-version:content-type;\r
+ bh=u8lee9onceZ5rvYjZmQlHL0pPhyF+LUQA25XwR83PjE=;\r
+ b=BJtBoijWdQsn1Mq5z1ch6b3mOa6hysyyHRBv+usGq6hIqZ3vrs6lNIFt+VabMXDZOb\r
+ ByPhMNOAUWQ+gemmUsBts6C08B9Z89qIPzMrk6u1j5QqhUFl6Ed/yFoPzPH4NjSawoLM\r
+ mlrLW8Y2wVTMYavRGhevWic56HK4axfGd2tmw=\r
+DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
+ h=sender:from:to:subject:in-reply-to:references:date:message-id\r
+ :mime-version:content-type;\r
+ b=OxWcPdPoZJFdfeRPOzbEtUC4ITlxQh6T0vN//WYF4SE2tWC7hiW1hhyGZVyeR6QemT\r
+ ARlV1/ds1BKulpPQHW1V2qO5AFfR81/rhRzC0xIu06SUaMc2U+QKVxD0qYnJVUibnhrw\r
+ mqz97x00C84dtV1IpsS7eMbspgzZA59FV8m0E=\r
+Received: by 10.204.148.78 with SMTP id o14mr4656564bkv.83.1258981609748;\r
+ Mon, 23 Nov 2009 05:06:49 -0800 (PST)\r
+Received: from kunyang (vawpc43.ethz.ch [129.132.59.11])\r
+ by mx.google.com with ESMTPS id 9sm5690477fks.52.2009.11.23.05.06.48\r
+ (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
+ Mon, 23 Nov 2009 05:06:48 -0800 (PST)\r
+Sender: Jed Brown <five9a2@gmail.com>\r
+From: Jed Brown <jed@59A2.org>\r
+To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org\r
+In-Reply-To: <87ocmtg9ni.fsf@yoom.home.cworth.org>\r
+References: <1258920736-14205-1-git-send-email-jed@59A2.org>\r
+ <87ocmtg9ni.fsf@yoom.home.cworth.org>\r
+Date: Mon, 23 Nov 2009 14:07:20 +0100\r
+Message-ID: <87y6lx4cfr.fsf@59A2.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Subject: Re: [notmuch] [PATCH] New function notmuch-search-operate-all:\r
+ operate on all messages in the current query.\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.12\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 23 Nov 2009 13:06:52 -0000\r
+\r
+On Mon, 23 Nov 2009 05:14:25 +0100, Carl Worth <cworth@cworth.org> wrote:\r
+> Second, I like that you just used the search string again, (as opposed\r
+> to just walking through the buffer looking at thread IDs). That seems\r
+> elegant.\r
+\r
+It was *easy*.\r
+\r
+> First, this creates a race condition in that the user will rightly\r
+> expect to only be adding/removing tags from the visible results. But if\r
+> new mail has been incorporated between creating the current view and\r
+> running '*' then threads could be tagged that were never seen and that\r
+> could be problematic.\r
+\r
+Agreed and I had also thought of the case you described. Note that\r
+Gmail does not solve the race condition. When in summary mode:\r
+\r
+* Marking a thread as read applies to all messages in the thread. The\r
+ thread contents are being updated concurrently so you may mark threads\r
+ you have already seen.\r
+\r
+* Same story with archiving (aka. remove inbox).\r
+\r
+* Starring a thread applies to the last message in the thread, this\r
+ could be a newly arrived message that is not currently displayed.\r
+\r
+I think that handling a concurrent changes to the match results is a\r
+somewhat hard problem. You have to store the message ids of everything\r
+in the current query if you want to avoid the race.\r
+\r
+> Second, since we're in the search view which shows threads, we should\r
+> really be operating on threads. But this tag command won't work like the\r
+> '+' and '-' commands in this buffer. Those commands will add/remove a\r
+> tag to/from every message in the thread[*]. The new '*' command, however\r
+> will only be changing tags on messages that match the query.\r
+\r
+I'm not convinced that we want to operate on the entire thread.\r
+Applying the tag only to the matched messages is enough to find the\r
+thread, and it may really be desirable to only have it applied to\r
+certain messages in the thread. For example, I might have constructed\r
+an elaborate query to find five messages, including a couple that are\r
+burried in 100-message threads in which case I would definitely not want\r
+to tag entire threads.\r
+\r
+> So I think we should fix both of these issues by looping over each line\r
+> of the buffer and calling (notmuch-search-add-tag) or\r
+> (notmuch-search-remove-tag).\r
+\r
+Presumably you don't mean this literally because that would be horribly\r
+slow. What you want is to gather up all the message ids in all the\r
+threads with at least one message matching the current query (and\r
+currently displayed). I think this is only possible if notmuch-search\r
+holds message IDs for everything in the matched threads. If we are\r
+happy to just tag the matched messages instead of the entire thread, we\r
+would only store the message ids for the matched messages.\r
+\r
+> Oh, here's one: We could add something like "notmuch tag --expecting=\r
+> 1/23 <search-terms>" that would not do the tag unless the search string\r
+> matched 1 message out of 23 total messages in the thread. Then we could\r
+> give a warning to the user.\r
+\r
+I like this, but it still presents a minor race condition (suppose\r
+another client swaps the unread tag on two messages in the same thread).\r
+The only way to guarantee that you are operating on the displayed\r
+messages is to store their message ids.\r
+\r
+> That works for the single-thread case, but the warning would be harder\r
+> for the user to deal with in the '*' case. Or maybe not---the emacs\r
+> function could just stop on the first line with the error and then the\r
+> user would see what's going on.\r
+\r
+If you can implement notmuch tag --expecting with similar efficiency to\r
+the present, then I would vote for notifying the user and asking for\r
+confirmation if the number of matches has changed. This would be\r
+significantly safer than what Gmail does which ought to be sufficient\r
+for now given the age of notmuch.\r
+\r
+\r
+Jed\r
projects / notmuch-archives.git / commitdiff