Re: [BUG] Emacs UI dropping every 25th line, roughly

diff --git a/8f/7bc6a3bb536cfc96008a1329d0e10557a50ee9 b/8f/7bc6a3bb536cfc96008a1329d0e10557a50ee9
new file mode 100644 (file)
index 0000000..a0e703e
--- /dev/null
+++ b/8f/7bc6a3bb536cfc96008a1329d0e10557a50ee9
@@ -0,0 +1,97 @@
+Return-Path: <thomas@schwinge.name>\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 B4DB8431FB6\r
+       for <notmuch@notmuchmail.org>; Wed,  2 Feb 2011 15:57:49 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_NONE=-0.0001] 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 y8MlmeEB-CSN for <notmuch@notmuchmail.org>;\r
+       Wed,  2 Feb 2011 15:57:48 -0800 (PST)\r
+Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de\r
+       [80.67.31.37])\r
+       by olra.theworths.org (Postfix) with ESMTP id 83B94431FB5\r
+       for <notmuch@notmuchmail.org>; Wed,  2 Feb 2011 15:57:48 -0800 (PST)\r
+Received: from [87.180.46.33] (helo=stokes.schwinge.homeip.net)\r
+       by smtprelay03.ispgateway.de with esmtpa (Exim 4.68)\r
+       (envelope-from <thomas@schwinge.name>) id 1PkmZk-0000PV-KM\r
+       for notmuch@notmuchmail.org; Thu, 03 Feb 2011 00:57:28 +0100\r
+Received: (qmail 7021 invoked from network); 2 Feb 2011 23:57:05 -0000\r
+Received: from schwinge.homeip.net (87.180.46.33)\r
+       by stokes.schwinge.homeip.net with QMQP; 2 Feb 2011 23:57:05 -0000\r
+Received: (nullmailer pid 16855 invoked by uid 1000);\r
+       Wed, 02 Feb 2011 23:57:04 -0000\r
+From: Thomas Schwinge <thomas@schwinge.name>\r
+To: notmuch@notmuchmail.org\r
+Subject: Re: [BUG] Emacs UI dropping every 25th line, roughly\r
+Date: Thu,  3 Feb 2011 00:56:37 +0100\r
+Message-Id: <1296690999-16542-1-git-send-email-thomas@schwinge.name>\r
+X-Mailer: git-send-email 1.7.1\r
+In-Reply-To: <87zkqeiffj.fsf@kepler.schwinge.homeip.net>\r
+References: <87zkqeiffj.fsf@kepler.schwinge.homeip.net>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=UTF-8\r
+Content-Transfer-Encoding: 8bit\r
+X-Df-Sender: thomas@schwinge.name\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\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: Wed, 02 Feb 2011 23:57:49 -0000\r
+\r
+Hallo!\r
+\r
+Here is the problem, as suspected.\r
+\r
+On Wed, 02 Feb 2011 17:12:16 +0100, I wrote:\r
+> At this / in the middle of this point, the 4 KiB size is hit.  After\r
+> accumulating some more (notice the 3.6 seconds delay), Emacs read()s the\r
+> first chunk (line breaks inserted for clarity):\r
+> \r
+>     16:26:57.928798 read(8, "[first two dozen results]"\r
+>                             "thread:00000000000006c7   2009-12-16 [2/2] Thomas Schwinge; [subject] ([flags])\n"\r
+>                             "t", 4096) = 4095\r
+> \r
+> The last result line is obviously incomplete, only the `t' so far.\r
+\r
+notmuch.el:notmuch-search-process-filter will be called for processing\r
+these lines.  It'll do fine up to the single `t' -- which simply isn't a\r
+conforming line and thus will be dropped (which is questionable behavior\r
+anyway, I would think?).\r
+\r
+> There is more to be read, so Emacs quickly goes on with the next chunk:\r
+> \r
+>     16:26:57.966247 read(8, "hread:0000000000000ac4   2009-12-16 [1/1] jsm28@sourceware.org; [subject] ([flags])\n"\r
+>                             "[more results]", 4096) = 4095\r
+\r
+Same thing; this time ``hread:[...]'' isn't a confirming line, and will\r
+be dropped.  After that, regular processing continues.\r
+\r
+\r
+This problem has been around as of the beginning of the incremental /\r
+asynchronous search results changes, as documented in\r
+id:87aayatnw4.fsf@yoom.home.cworth.org on 2009-11-25; 2009-11-24's commit\r
+93af7b574598637c2766dd1f8ef343962c9a8efb.\r
+\r
+\r
+Emacs LISP is not my speciality, neither is any other LISP dialect, so\r
+someone please carefully review this.\r
+\r
+\r
+Grüße (und gute Nacht...),\r
+ Thomas\r
+\r