[PATCH 2/3] ruby: allow build with RUNPATH
[notmuch-archives.git] / 8f / 7bc6a3bb536cfc96008a1329d0e10557a50ee9
1 Return-Path: <thomas@schwinge.name>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id B4DB8431FB6\r
6         for <notmuch@notmuchmail.org>; Wed,  2 Feb 2011 15:57:49 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: 0\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_NONE=-0.0001] autolearn=disabled\r
13 Received: from olra.theworths.org ([127.0.0.1])\r
14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
15         with ESMTP id y8MlmeEB-CSN for <notmuch@notmuchmail.org>;\r
16         Wed,  2 Feb 2011 15:57:48 -0800 (PST)\r
17 Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de\r
18         [80.67.31.37])\r
19         by olra.theworths.org (Postfix) with ESMTP id 83B94431FB5\r
20         for <notmuch@notmuchmail.org>; Wed,  2 Feb 2011 15:57:48 -0800 (PST)\r
21 Received: from [87.180.46.33] (helo=stokes.schwinge.homeip.net)\r
22         by smtprelay03.ispgateway.de with esmtpa (Exim 4.68)\r
23         (envelope-from <thomas@schwinge.name>) id 1PkmZk-0000PV-KM\r
24         for notmuch@notmuchmail.org; Thu, 03 Feb 2011 00:57:28 +0100\r
25 Received: (qmail 7021 invoked from network); 2 Feb 2011 23:57:05 -0000\r
26 Received: from schwinge.homeip.net (87.180.46.33)\r
27         by stokes.schwinge.homeip.net with QMQP; 2 Feb 2011 23:57:05 -0000\r
28 Received: (nullmailer pid 16855 invoked by uid 1000);\r
29         Wed, 02 Feb 2011 23:57:04 -0000\r
30 From: Thomas Schwinge <thomas@schwinge.name>\r
31 To: notmuch@notmuchmail.org\r
32 Subject: Re: [BUG] Emacs UI dropping every 25th line, roughly\r
33 Date: Thu,  3 Feb 2011 00:56:37 +0100\r
34 Message-Id: <1296690999-16542-1-git-send-email-thomas@schwinge.name>\r
35 X-Mailer: git-send-email 1.7.1\r
36 In-Reply-To: <87zkqeiffj.fsf@kepler.schwinge.homeip.net>\r
37 References: <87zkqeiffj.fsf@kepler.schwinge.homeip.net>\r
38 MIME-Version: 1.0\r
39 Content-Type: text/plain; charset=UTF-8\r
40 Content-Transfer-Encoding: 8bit\r
41 X-Df-Sender: thomas@schwinge.name\r
42 X-BeenThere: notmuch@notmuchmail.org\r
43 X-Mailman-Version: 2.1.13\r
44 Precedence: list\r
45 List-Id: "Use and development of the notmuch mail system."\r
46         <notmuch.notmuchmail.org>\r
47 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
48         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
49 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
50 List-Post: <mailto:notmuch@notmuchmail.org>\r
51 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
52 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
53         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
54 X-List-Received-Date: Wed, 02 Feb 2011 23:57:49 -0000\r
55 \r
56 Hallo!\r
57 \r
58 Here is the problem, as suspected.\r
59 \r
60 On Wed, 02 Feb 2011 17:12:16 +0100, I wrote:\r
61 > At this / in the middle of this point, the 4 KiB size is hit.  After\r
62 > accumulating some more (notice the 3.6 seconds delay), Emacs read()s the\r
63 > first chunk (line breaks inserted for clarity):\r
64\r
65 >     16:26:57.928798 read(8, "[first two dozen results]"\r
66 >                             "thread:00000000000006c7   2009-12-16 [2/2] Thomas Schwinge; [subject] ([flags])\n"\r
67 >                             "t", 4096) = 4095\r
68\r
69 > The last result line is obviously incomplete, only the `t' so far.\r
70 \r
71 notmuch.el:notmuch-search-process-filter will be called for processing\r
72 these lines.  It'll do fine up to the single `t' -- which simply isn't a\r
73 conforming line and thus will be dropped (which is questionable behavior\r
74 anyway, I would think?).\r
75 \r
76 > There is more to be read, so Emacs quickly goes on with the next chunk:\r
77\r
78 >     16:26:57.966247 read(8, "hread:0000000000000ac4   2009-12-16 [1/1] jsm28@sourceware.org; [subject] ([flags])\n"\r
79 >                             "[more results]", 4096) = 4095\r
80 \r
81 Same thing; this time ``hread:[...]'' isn't a confirming line, and will\r
82 be dropped.  After that, regular processing continues.\r
83 \r
84 \r
85 This problem has been around as of the beginning of the incremental /\r
86 asynchronous search results changes, as documented in\r
87 id:87aayatnw4.fsf@yoom.home.cworth.org on 2009-11-25; 2009-11-24's commit\r
88 93af7b574598637c2766dd1f8ef343962c9a8efb.\r
89 \r
90 \r
91 Emacs LISP is not my speciality, neither is any other LISP dialect, so\r
92 someone please carefully review this.\r
93 \r
94 \r
95 Grüße (und gute Nacht...),\r
96  Thomas\r
97 \r