Re: strange search behaviour in emacs

diff --git a/86/019289acbe116972fcb2e0906ed16f6a0d1b0d b/86/019289acbe116972fcb2e0906ed16f6a0d1b0d
new file mode 100644 (file)
index 0000000..91cc1ec
--- /dev/null
+++ b/86/019289acbe116972fcb2e0906ed16f6a0d1b0d
@@ -0,0 +1,81 @@
+Return-Path: <sebastian.fischmeister@uwaterloo.ca>\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 29EE0431E82\r
+       for <notmuch@notmuchmail.org>; Tue, 24 Mar 2015 18:35:31 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.138\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.138 tagged_above=-999 required=5\r
+       tests=[DNS_FROM_AHBL_RHSBL=2.438, RCVD_IN_DNSWL_MED=-2.3]\r
+       autolearn=disabled\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 fKHiQeS2yljF for <notmuch@notmuchmail.org>;\r
+       Tue, 24 Mar 2015 18:35:28 -0700 (PDT)\r
+Received: from mailchk-m01.uwaterloo.ca (mailservices.uwaterloo.ca\r
+       [129.97.128.141])\r
+       (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id E4412431E62\r
+       for <notmuch@notmuchmail.org>; Tue, 24 Mar 2015 18:35:27 -0700 (PDT)\r
+Received: from connect.uwaterloo.ca (connhub1.connect.uwaterloo.ca\r
+       [129.97.149.113])\r
+       by mailchk-m01.uwaterloo.ca (8.14.4/8.14.4) with ESMTP id\r
+       t2P1ZNUJ008285\r
+       (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK);\r
+       Tue, 24 Mar 2015 21:35:23 -0400\r
+Received: from uwaterloo.ca (172.16.37.44) by connhub1.connect.uwaterloo.ca\r
+       (129.97.149.113) with Microsoft SMTP Server (TLS) id 14.3.210.2;\r
+       Tue, 24 Mar 2015 21:35:22 -0400\r
+From: Sebastian Fischmeister <sfischme@uwaterloo.ca>\r
+To: David Bremner <david@tethera.net>, notmuch <notmuch@notmuchmail.org>\r
+Subject: Re: strange search behaviour in emacs\r
+In-Reply-To: <87bnji6vur.fsf@maritornes.cs.unb.ca>\r
+References: <87twxbypqw.fsf@uwaterloo.ca>\r
+ <87bnji6vur.fsf@maritornes.cs.unb.ca>\r
+X-Homepage: http://esg.uwaterloo.ca\r
+Date: Tue, 24 Mar 2015 21:35:22 -0400\r
+Message-ID: <87vbhpvp0x.fsf@uwaterloo.ca>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-UUID: d40a2ff0-c49d-4a24-b8d2-01a14ef2202d\r
+X-Miltered: at mailchk-m01 with ID 551210DB.000 by Joe's j-chkmail\r
+       (http://j-chkmail.ensmp.fr)!\r
+X-Virus-Scanned: clamav-milter 0.98.5 at mailchk-m01\r
+X-Virus-Status: Clean\r
+X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3\r
+       (mailchk-m01.uwaterloo.ca [129.97.128.141]);\r
+       Tue, 24 Mar 2015 21:35:24 -0400 (EDT)\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+Reply-To: sfischme@uwaterloo.ca\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: Wed, 25 Mar 2015 01:35:31 -0000\r
+\r
+> I suspect this is related to asynch loading. The first query is still\r
+> filling into the buffer, and emacs doesn't starting filling the second\r
+> buffer until the first search finishes. In my experiments it\r
+> _eventually_ does the second query.\r
+\r
+You are correct. I confirm that the second query eventually gets\r
+executed. \r
+\r
+> It just takes a while. I agree it would be nice if there was some UI\r
+> hint before the first result arrives.\r
+\r
+Yes, a simple update in the statusbar for the mode name would be a\r
+possible approach.\r
+\r
+  Sebastian\r