Re: [PATCH] NEWS: initial NEWS for 0.22.1
[notmuch-archives.git] / 34 / f4e5307b8814f8bc712d4a6ef3364cb3d33129
1 Return-Path: <m.walters@qmul.ac.uk>\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 B2B79431FB6\r
6         for <notmuch@notmuchmail.org>; Tue, 19 Jun 2012 00:07:56 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: 1.401\r
10 X-Spam-Level: *\r
11 X-Spam-Status: No, score=1.401 tagged_above=-999 required=5\r
12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
13         FREEMAIL_REPLY=2.499, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3]\r
14         autolearn=disabled\r
15 Received: from olra.theworths.org ([127.0.0.1])\r
16         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
17         with ESMTP id Y0YHboPn1yKw for <notmuch@notmuchmail.org>;\r
18         Tue, 19 Jun 2012 00:07:56 -0700 (PDT)\r
19 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
20         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
21         (No client certificate requested)\r
22         by olra.theworths.org (Postfix) with ESMTPS id BA5FE431FAF\r
23         for <notmuch@notmuchmail.org>; Tue, 19 Jun 2012 00:07:55 -0700 (PDT)\r
24 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
25         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
26         (envelope-from <m.walters@qmul.ac.uk>)\r
27         id 1SgsXY-0003gN-Dp; Tue, 19 Jun 2012 08:07:54 +0100\r
28 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]\r
29         helo=localhost)\r
30         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
31         (envelope-from <m.walters@qmul.ac.uk>)\r
32         id 1SgsXY-0002F6-1s; Tue, 19 Jun 2012 08:07:52 +0100\r
33 From: Mark Walters <markwalters1009@gmail.com>\r
34 To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
35  notmuch@notmuchmail.org\r
36 Subject: Re: Notmuch Pick\r
37 In-Reply-To: <87zk80ilt9.fsf@servo.finestructure.net>\r
38 References: <87395ump0d.fsf@qmul.ac.uk>\r
39         <87zk80ilt9.fsf@servo.finestructure.net>\r
40 User-Agent: Notmuch/0.13.2+63~g548a9bf (http://notmuchmail.org) Emacs/23.4.1\r
41         (x86_64-pc-linux-gnu)\r
42 Date: Tue, 19 Jun 2012 08:07:50 +0100\r
43 Message-ID: <87mx3zok3d.fsf@qmul.ac.uk>\r
44 MIME-Version: 1.0\r
45 Content-Type: text/plain; charset=us-ascii\r
46 X-Sender-Host-Address: 94.192.233.223\r
47 X-QM-SPAM-Info: Sender has good ham record.  :)\r
48 X-QM-Body-MD5: 550aeb014d2c6b6a585f11d6ab22dba5 (of first 20000 bytes)\r
49 X-SpamAssassin-Score: -1.2\r
50 X-SpamAssassin-SpamBar: -\r
51 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
52         determine if it is\r
53         spam. We require at least 5.0 points to mark a message as spam.\r
54         This message scored -1.2 points.\r
55         Summary of the scoring: \r
56         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
57         *      medium trust\r
58         *      [138.37.6.40 listed in list.dnswl.org]\r
59         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
60         provider *      (markwalters1009[at]gmail.com)\r
61         * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
62         *      domain\r
63         *  1.0 FREEMAIL_REPLY From and body contain different freemails\r
64         *  0.1 AWL AWL: From: address is in the auto white-list\r
65 X-QM-Scan-Virus: ClamAV says the message is clean\r
66 X-BeenThere: notmuch@notmuchmail.org\r
67 X-Mailman-Version: 2.1.13\r
68 Precedence: list\r
69 List-Id: "Use and development of the notmuch mail system."\r
70         <notmuch.notmuchmail.org>\r
71 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
72         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
73 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
74 List-Post: <mailto:notmuch@notmuchmail.org>\r
75 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
76 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
77         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
78 X-List-Received-Date: Tue, 19 Jun 2012 07:07:56 -0000\r
79 \r
80 \r
81 On Mon, 18 Jun 2012, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
82 > On Sat, Jun 16 2012, Mark Walters <markwalters1009@gmail.com> wrote:\r
83 >> Since I have had various requests for notmuch pick\r
84 >> (id:"1329096015-8078-2-git-send-email-markwalters1009@gmail.com") so I\r
85 >> have started a git repository at\r
86 >> git://github.com/markwalters1009/notmuch.git\r
87 >>\r
88 >> The branch pick-6 is the current version. My intention is to start a new\r
89 >> branch each time I rebase on to current master but this may change. (I\r
90 >> suggest that people do not rely on a consistent history for this repository)\r
91 >\r
92 > Hey, Mark.  I took a look at this and I have a couple of comments:\r
93 >\r
94 > 726e11aff69e10499a9855e0ac2f15e518985c1f\r
95 >     cli: notmuch-show with framing newlines between threads in JSON.\r
96 >\r
97 > This patch introduces a change in the json output format, but there is\r
98 > no subsequent update of the test suite, so it's causing a lot of test\r
99 > failures.  Obviously this needs to be fixed, but it would probably be\r
100 > nice to include a couple of other tests for the pick output itself.  At\r
101 > the very least a sanity test to check that it's working at all would be\r
102 > sufficient initially.\r
103 \r
104 Hi \r
105 \r
106 As you say several tests do need fixing: I\r
107 thought I would leave that until people said they were basically happy\r
108 with the change. \r
109 \r
110 I am not sure about sanity tests for pick: how would that work while it\r
111 lives in contrib? Obviously it would need some tests before coming in to\r
112 proper mainline.\r
113 \r
114 > Would it also be useful to make this same change for the search out, for\r
115 > consistency?  I notice the search output now uses newlines between all\r
116 > fields, which should help for asynchronous processing, but it might be\r
117 > nice to put newline separators between the initial and final brackets as\r
118 > well.\r
119 \r
120 Right. \r
121 \r
122 > df97df62b70b884a1cd367360ed6ff7eda0e8af6\r
123 >     cli: add --headers_only option to notmuch-show.c\r
124 >\r
125 > Your comment in this patch is very interesting:\r
126 >\r
127 >     This is used by notmuch-pick.el (although not needed) because it gives a\r
128 >     speed-up of at least a factor of a two; moreover it reduces the memory\r
129 >     usage in emacs hugely.\r
130 >\r
131 > The only difference between the regular show json output and the\r
132 > --headers-only output, as far as I can tell, is the presence of the\r
133 > content of text/plain parts if they exist in the message.  We previously\r
134 > had a discussion about the show output not including any part bodies at\r
135 > all, but we decided that the inclusion of text/plain bodies shouldn't\r
136 > affect anything, so why not include them.  If they actually do, then I\r
137 > argue we should just move to having show json not include any body parts\r
138 > at all by default, and just have them be retrieved individually like we\r
139 > do currently for non-text/plain parts.  This would make things cleaner,\r
140 > and would get rid of the need to have this extra option, which really\r
141 > doesn't produce a significantly different output.\r
142 \r
143 For one use of pick (displaying the structure of a single thread) this\r
144 is not important (and the asynchronous stuff is irrelevant too). For\r
145 another use of displaying the thread structure of a whole "folder" of\r
146 messages it is important. For example the output of \r
147 \r
148 notmuch show tag:notmuch\r
149 \r
150 is about 70MB on my system, whereas with the --headers-only option this\r
151 drops to about 7MB. Note Emacs uses substantially  more than this much\r
152 memory to actually process the JSON, and on a low-powered laptop this\r
153 is enough to cause a swap-storm.\r
154 \r
155 Your suggestion of just not including the text/plain is nice for\r
156 notmuch-pick, and is very simple (a single line change). However, it\r
157 does seem to slow the emacs show mode down noticeably on large threads\r
158 (something like 2s to 4s on a thread with 180 messages) so I worry that\r
159 this change might annoy people. What do you think?\r
160 \r
161 Many thanks for the comments!\r
162 \r
163 Mark\r