Re: [PATCH v2] emacs: Report a lack of matches when calling `notmuch-show'.
authorDavid Edmondson <dme@dme.org>
Wed, 10 Feb 2016 19:52:17 +0000 (19:52 +0000)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 23:21:05 +0000 (16:21 -0700)
01/f86c2a02d7540bfeb45d7042919cc8c3163d00 [new file with mode: 0644]

diff --git a/01/f86c2a02d7540bfeb45d7042919cc8c3163d00 b/01/f86c2a02d7540bfeb45d7042919cc8c3163d00
new file mode 100644 (file)
index 0000000..09dbfb3
--- /dev/null
@@ -0,0 +1,118 @@
+Return-Path: <dme@dme.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id A43E36DE0BF6\r
+ for <notmuch@notmuchmail.org>; Wed, 10 Feb 2016 11:52:23 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.115\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5\r
+ tests=[AWL=-0.048, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,\r
+ RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01,\r
+ RCVD_IN_MSPIKE_WL=-0.01, SPF_NEUTRAL=0.652, UNPARSEABLE_RELAY=0.001]\r
+ autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id pFNKbdTCvKgd for <notmuch@notmuchmail.org>;\r
+ Wed, 10 Feb 2016 11:52:21 -0800 (PST)\r
+Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com\r
+ [74.125.82.65]) by arlo.cworth.org (Postfix) with ESMTPS id 5D2496DE0B36 for\r
+ <notmuch@notmuchmail.org>; Wed, 10 Feb 2016 11:52:21 -0800 (PST)\r
+Received: by mail-wm0-f65.google.com with SMTP id g62so6349899wme.2\r
+ for <notmuch@notmuchmail.org>; Wed, 10 Feb 2016 11:52:21 -0800 (PST)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=dme-org.20150623.gappssmtp.com; s=20150623;\r
+ h=to:subject:in-reply-to:references:from:date:message-id:mime-version\r
+ :content-type; bh=f3uIJvwAJ0naWN3oknSrqGvMbilTu6vQZwbAfyZwQ2A=;\r
+ b=FLm3vvzoOKqbmT8QCAsAF1NZzZGxWwsi6AzQrLCd5rs9m0vNbX3z8/mgZbwzGQ9JCt\r
+ w7U4Dg/Z+dC+MXwBKdsnYKBzgvc/3E2+vT3sVs7TRbhLPVFbGJuvpHRlHPltBPgzAFvp\r
+ xN+aI6qASnfYXbTwBjI7WKp/ehtlLuzBjq9ZTYlcc904c1WufnsYGJsekTKfVTp/6EZs\r
+ uA7RY2+AxATERKhUr6PCPhzezlzbfW7PDymSfLqV8qQxpYQjzCYmFA9OlQCMmfHNAfZK\r
+ 1qS+oK6nNOtp6UtK65dj6MQasajjwG1hCBMnDrZS9D0gOQaOhQZCUrIFf7O6GwFTpBUZ\r
+ V4mA==\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=1e100.net; s=20130820;\r
+ h=x-gm-message-state:to:subject:in-reply-to:references:from:date\r
+ :message-id:mime-version:content-type;\r
+ bh=f3uIJvwAJ0naWN3oknSrqGvMbilTu6vQZwbAfyZwQ2A=;\r
+ b=gK776/OXtXOBZHCKJjc1XP1aHMemE0r0U1swnM9HuXBi+aXe50+7DaTPbioY82Oa3C\r
+ ooUm8H0Y40qBj2FAhwAojLEh2pElq47TVUl82iNfl702MfNjuuFz5zC0egax26sS4pCf\r
+ d/JteP4i/7AXqIJhObYbFrxas5YEHNcVFTh1yEB6DpE1FT+/M0i+gxjpW6Wd3O10+EdA\r
+ nmnavOnCdYvoCllnqAD/tK9s/c2IPBKYpKvrlHMOIqnrv+arK+CaBDtuvDQ1r2bEgKjJ\r
+ i8eWygAk2Y4T0aM8CIzeW1USzQZRyrOVglVLTsI7rVACLZgZ6tvsqE0xjpXFsdIha4vQ\r
+ ouUw==\r
+X-Gm-Message-State:\r
+ AG10YORwQ41x/l1aWbyVwh4f2Td0eOcTFl+CL+fsJF7OhAmA9E4s2DklinpN9GaMapmSSg==\r
+X-Received: by 10.28.173.71 with SMTP id w68mr13819810wme.88.1455133939824;\r
+ Wed, 10 Feb 2016 11:52:19 -0800 (PST)\r
+Received: from disaster-area.hh.sledj.net\r
+ ([2a01:348:1a2:1:ea39:35ff:fe2c:a227])\r
+ by smtp.gmail.com with ESMTPSA id w136sm23721146wmw.0.2016.02.10.11.52.18\r
+ (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\r
+ Wed, 10 Feb 2016 11:52:18 -0800 (PST)\r
+Received: from localhost (disaster-area.hh.sledj.net [local])\r
+ by disaster-area.hh.sledj.net (OpenSMTPD) with ESMTPA id cab25f7c;\r
+ Wed, 10 Feb 2016 19:52:17 +0000 (UTC)\r
+To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH v2] emacs: Report a lack of matches when calling\r
+ `notmuch-show'.\r
+In-Reply-To: <87oabo5rix.fsf@qmul.ac.uk>\r
+References: <1455112878-23497-1-git-send-email-dme@dme.org>\r
+ <1455112878-23497-2-git-send-email-dme@dme.org> <87oabo5rix.fsf@qmul.ac.uk>\r
+From: David Edmondson <dme@dme.org>\r
+Date: Wed, 10 Feb 2016 19:52:17 +0000\r
+Message-ID: <m260xw2vim.fsf@dme.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://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: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 10 Feb 2016 19:52:23 -0000\r
+\r
+On Wed, Feb 10 2016, Mark Walters wrote:\r
+> This basically looks fine to me and all tests pass. The code movement\r
+> and cleanup all looks fine.\r
+\r
+Thanks.\r
+\r
+> Two minor things, one tiny nit below; and I wonder whether just having\r
+> the buffer say "No search results" (or something similar) and leave\r
+> the user to kill it would be nicer than dinging (and more in line with\r
+> the way search and tree behave).\r
+>\r
+> [In some sense I think this way is right and search and tree are wrong,\r
+> but that is probably difficult to get round as search and tree run\r
+> asynchronously.]\r
+\r
+What if we did "notmuch count $query" first in the search and tree case,\r
+and did the "(ding) (message ...)" thing if the count returned 0? (Just\r
+wondering about whether having everything behave that way would be\r
+possible and acceptable.)\r
+\r
+The original impetus for this change was someone who hits an id: button\r
+that is either a false match (i.e it wasn't ever intended to be a\r
+notmuch reference) or for a message that they don't have. In both of\r
+those cases popping up a buffer that says only "No match." would be\r
+annoying. If we were considering the case where people are using "M-x\r
+notmuch-show", it seems less clear on the right thing to do, but overall\r
+I prefer this approach to the useless buffer that I have to kill/quit.\r
+\r
+>> +      ;; Cache the original tags for each message so that we can display\r
+>> +      ;; changes.\r
+>\r
+> ^^ I think "Store the original tags for each message" would be better,\r
+> particularly as this is nothing to do with the tag cache as used by say\r
+> notmuch-tag-clear-cache.\r
+\r
+Agreed - fixed.\r