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@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@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