Hallo! Here is the problem, as suspected.
On Wed, 02 Feb 2011 17:12:16 +0100, I wrote: > At this / in the middle of this point, the 4 KiB size is hit. After > accumulating some more (notice the 3.6 seconds delay), Emacs read()s the > first chunk (line breaks inserted for clarity): > > 16:26:57.928798 read(8, "[first two dozen results]" > "thread:00000000000006c7 2009-12-16 [2/2] > Thomas Schwinge; [subject] ([flags])\n" > "t", 4096) = 4095 > > The last result line is obviously incomplete, only the `t' so far. notmuch.el:notmuch-search-process-filter will be called for processing these lines. It'll do fine up to the single `t' -- which simply isn't a conforming line and thus will be dropped (which is questionable behavior anyway, I would think?). > There is more to be read, so Emacs quickly goes on with the next chunk: > > 16:26:57.966247 read(8, "hread:0000000000000ac4 2009-12-16 [1/1] jsm28 > at sourceware.org; [subject] ([flags])\n" > "[more results]", 4096) = 4095 Same thing; this time ``hread:[...]'' isn't a confirming line, and will be dropped. After that, regular processing continues. This problem has been around as of the beginning of the incremental / asynchronous search results changes, as documented in id:87aayatnw4.fsf at yoom.home.cworth.org on 2009-11-25; 2009-11-24's commit 93af7b574598637c2766dd1f8ef343962c9a8efb. Emacs LISP is not my speciality, neither is any other LISP dialect, so someone please carefully review this. Gr??e (und gute Nacht...), Thomas