--- /dev/null
+Return-Path: <jrollins@finestructure.net>\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 343D4431FB6\r
+ for <notmuch@notmuchmail.org>; Tue, 19 Jun 2012 11:52:09 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.29\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] 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 tZmcVK9aGbCF for <notmuch@notmuchmail.org>;\r
+ Tue, 19 Jun 2012 11:52:08 -0700 (PDT)\r
+Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
+ [131.215.239.19])\r
+ by olra.theworths.org (Postfix) with ESMTP id 75601431FAF\r
+ for <notmuch@notmuchmail.org>; Tue, 19 Jun 2012 11:52:08 -0700 (PDT)\r
+Received: from earth-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
+ by earth-doxen-postvirus (Postfix) with ESMTP id 1A87E66E00FE;\r
+ Tue, 19 Jun 2012 11:52:08 -0700 (PDT)\r
+X-Spam-Scanned: at Caltech-IMSS on earth-doxen by amavisd-new\r
+Received: from finestructure.net (gwave-111.ligo.caltech.edu\r
+ [131.215.114.111]) (Authenticated sender: jrollins) by earth-doxen-submit\r
+ (Postfix) with ESMTP id 7FA9166E008D; Tue, 19 Jun 2012 11:52:04 -0700 (PDT)\r
+Received: by finestructure.net (Postfix, from userid 1000)\r
+ id 49D8293D; Tue, 19 Jun 2012 11:52:04 -0700 (PDT)\r
+From: Jameson Graef Rollins <jrollins@finestructure.net>\r
+To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org\r
+Subject: Re: Notmuch Pick\r
+In-Reply-To: <87mx3zok3d.fsf@qmul.ac.uk>\r
+References: <87395ump0d.fsf@qmul.ac.uk>\r
+ <87zk80ilt9.fsf@servo.finestructure.net>\r
+ <87mx3zok3d.fsf@qmul.ac.uk>\r
+User-Agent: Notmuch/0.13.2+53~g1567997 (http://notmuchmail.org) Emacs/23.4.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Tue, 19 Jun 2012 11:52:01 -0700\r
+Message-ID: <87zk7z2kz2.fsf@servo.finestructure.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+ micalg=pgp-sha256; protocol="application/pgp-signature"\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: Tue, 19 Jun 2012 18:52:09 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Tue, Jun 19 2012, Mark Walters <markwalters1009@gmail.com> wrote:\r
+> As you say several tests do need fixing: I\r
+> thought I would leave that until people said they were basically happy\r
+> with the change.=20\r
+\r
+Yeah, but failing tests are basically a non-starter for me. You can\r
+maybe get away with not adding new tests during development, but I'm\r
+unlikely to even try out the patches if a bunch of the existing tests\r
+are failing.\r
+\r
+> I am not sure about sanity tests for pick: how would that work while it\r
+> lives in contrib? Obviously it would need some tests before coming in to\r
+> proper mainline.\r
+\r
+Since you're not actually submitting these patches yet, does it really\r
+need to live in contrib? The goal is for it to ultimately *not* live in\r
+contrib, so I would say just go ahead and make them apply in the main\r
+source.\r
+\r
+An example of a sanity test I'm talking about is simply display the pick\r
+thread for something and test that it looks like expected. Sort of a\r
+zeroth order thing. There are other emacs tests that do the same sort\r
+of thing so it shouldn't be too hard to add.\r
+\r
+>> Would it also be useful to make this same change for the search out, for\r
+>> consistency? I notice the search output now uses newlines between all\r
+>> fields, which should help for asynchronous processing, but it might be\r
+>> nice to put newline separators between the initial and final brackets as\r
+>> well.\r
+>\r
+> Right.=20\r
+\r
+I would say go ahead and send to the list any patches that come up in\r
+development that are generally useful. Especially if they're small like\r
+this they are likely to applied before this series, so it will be\r
+smaller and easier to read when the times comes.\r
+\r
+>> df97df62b70b884a1cd367360ed6ff7eda0e8af6\r
+>> cli: add --headers_only option to notmuch-show.c\r
+>>\r
+>> Your comment in this patch is very interesting:\r
+>>\r
+>> This is used by notmuch-pick.el (although not needed) because it giv=\r
+es a\r
+>> speed-up of at least a factor of a two; moreover it reduces the memo=\r
+ry\r
+>> usage in emacs hugely.\r
+>>\r
+>> The only difference between the regular show json output and the\r
+>> --headers-only output, as far as I can tell, is the presence of the\r
+>> content of text/plain parts if they exist in the message. We previously\r
+>> had a discussion about the show output not including any part bodies at\r
+>> all, but we decided that the inclusion of text/plain bodies shouldn't\r
+>> affect anything, so why not include them. If they actually do, then I\r
+>> argue we should just move to having show json not include any body parts\r
+>> at all by default, and just have them be retrieved individually like we\r
+>> do currently for non-text/plain parts. This would make things cleaner,\r
+>> and would get rid of the need to have this extra option, which really\r
+>> doesn't produce a significantly different output.\r
+>\r
+> For one use of pick (displaying the structure of a single thread) this\r
+> is not important (and the asynchronous stuff is irrelevant too). For\r
+> another use of displaying the thread structure of a whole "folder" of\r
+> messages it is important. For example the output of=20\r
+>\r
+> notmuch show tag:notmuch\r
+>\r
+> is about 70MB on my system, whereas with the --headers-only option this\r
+> drops to about 7MB. Note Emacs uses substantially more than this much\r
+> memory to actually process the JSON, and on a low-powered laptop this\r
+> is enough to cause a swap-storm.\r
+>\r
+> Your suggestion of just not including the text/plain is nice for\r
+> notmuch-pick, and is very simple (a single line change). However, it\r
+> does seem to slow the emacs show mode down noticeably on large threads\r
+> (something like 2s to 4s on a thread with 180 messages) so I worry that\r
+> this change might annoy people. What do you think?\r
+\r
+Threads that long are already a bit of a pain to deal with. But I think\r
+this reveals a weakness in the way we're displaying threads more than\r
+anything. It seems silly to me that we would retrieve all 180 messages\r
+From=20such a thread, and format all of them, only to then hide all but\r
+the one that the reader is seeing. I think this "pick" series\r
+illustrates this nicely. Maybe it would be better to refactor the\r
+current emacs show mode to only retrieve parts for messages that are\r
+being displayed. I'm not sure how difficult that would be, though.\r
+\r
+I would also like to have access to more of the message headers in show\r
+mode. For instance, in emacs I want to access more headers with\r
+notmuch-message-headers than are currently available. Having json\r
+always include all headers might be a bit of a performance hit for some\r
+messages with lots of headers, but it would allow callers access to\r
+headers they don't currently have access to at all.\r
+\r
+So I think it would be nice and clean if the default json output\r
+included all the message headers and the message structure, and then\r
+part contents could be retrieved individually. I imagine show mode\r
+could be restructured such that it could use this efficiently.\r
+\r
+jamie.\r
+\r
+PS. where did the name "pick" come from? It doesn't seem to fit with\r
+the functionality to me.\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.12 (GNU/Linux)\r
+\r
+iQIcBAEBCAAGBQJP4MpSAAoJEO00zqvie6q8HWIP/3zuS2RWqZVQyvq7SPhwCtFB\r
+9zmWoYvHtTwmeGqgBCAbfVKZVzczSSVW7JIltDL5hT91IDnBY5VT5vifz0fecBz+\r
+1U9H0DT5fdU84WB8kzGgvzptHVEbO0QMWodiPRbFjfBk1WovB7EVN1OPfBQE27lw\r
+x7okLDEKg0wAXLdFnXC1swoPCxSYVv2Zr+joJwLBmyLBW85Hm+cEmP/ZrMAVrmBe\r
+zbl9phzD7XbSudU5UE0sg1AjKfcYbZpeqmgKqdXn38e+0JHQCZsWptBfu/8SDz09\r
+9A6+dYSIVKJ8Gv25JkdI9gIKHgh8exc05DH+8KgDEa+L4srpbHpG3DfvedS1WpBy\r
+n4xQchF1DXcTk89G228pP0EaNLHR6eF82TqJ2vIfe+csTU0VnaxFsTbXS6Skup1F\r
+UvTedyC005el3Ej7quLI43JQa39CktsVT8sEUiqdi9HQpcdmC/PiU/hHdloLjEvS\r
+ym1qy45Vfi/hKmoLKVCERmkMVn+i0lkW76m7FVX1oDdM5LjqIYWRDF2JdhP5/whW\r
+VT2YCDbwdejKMbB906fZk9tMpvi/ui477gCOYMwf056kJ0iftsj/Jxolc08aHTs5\r
+uyRd+5XWdUjCMdGb6NuuxSpoG1B7k7M5iZmSBaKmyDKR+MMPuGUzHBykbehTU4EF\r
+R3hVLYoSH5if5SkBFJv5\r
+=5XeH\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r
projects / notmuch-archives.git / commitdiff