df/c64725e1ce181a05a6accfd6d843749381b963

   1 Return-Path: <jrollins@finestructure.net>\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 343D4431FB6\r
   6         for <notmuch@notmuchmail.org>; Tue, 19 Jun 2012 11:52:09 -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: -2.29\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] 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 tZmcVK9aGbCF for <notmuch@notmuchmail.org>;\r
  16         Tue, 19 Jun 2012 11:52:08 -0700 (PDT)\r
  17 Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
  18         [131.215.239.19])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 75601431FAF\r
  20         for <notmuch@notmuchmail.org>; Tue, 19 Jun 2012 11:52:08 -0700 (PDT)\r
  21 Received: from earth-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
  22         by earth-doxen-postvirus (Postfix) with ESMTP id 1A87E66E00FE;\r
  23         Tue, 19 Jun 2012 11:52:08 -0700 (PDT)\r
  24 X-Spam-Scanned: at Caltech-IMSS on earth-doxen by amavisd-new\r
  25 Received: from finestructure.net (gwave-111.ligo.caltech.edu\r
  26  [131.215.114.111])     (Authenticated sender: jrollins)        by earth-doxen-submit\r
  27  (Postfix) with ESMTP id 7FA9166E008D;  Tue, 19 Jun 2012 11:52:04 -0700 (PDT)\r
  28 Received: by finestructure.net (Postfix, from userid 1000)\r
  29         id 49D8293D; Tue, 19 Jun 2012 11:52:04 -0700 (PDT)\r
  30 From: Jameson Graef Rollins <jrollins@finestructure.net>\r
  31 To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org\r
  32 Subject: Re: Notmuch Pick\r
  33 In-Reply-To: <87mx3zok3d.fsf@qmul.ac.uk>\r
  34 References: <87395ump0d.fsf@qmul.ac.uk>\r
  35         <87zk80ilt9.fsf@servo.finestructure.net>\r
  36         <87mx3zok3d.fsf@qmul.ac.uk>\r
  37 User-Agent: Notmuch/0.13.2+53~g1567997 (http://notmuchmail.org) Emacs/23.4.1\r
  38         (x86_64-pc-linux-gnu)\r
  39 Date: Tue, 19 Jun 2012 11:52:01 -0700\r
  40 Message-ID: <87zk7z2kz2.fsf@servo.finestructure.net>\r
  41 MIME-Version: 1.0\r
  42 Content-Type: multipart/signed; boundary="=-=-=";\r
  43         micalg=pgp-sha256; protocol="application/pgp-signature"\r
  44 X-BeenThere: notmuch@notmuchmail.org\r
  45 X-Mailman-Version: 2.1.13\r
  46 Precedence: list\r
  47 List-Id: "Use and development of the notmuch mail system."\r
  48         <notmuch.notmuchmail.org>\r
  49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  50         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  51 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  52 List-Post: <mailto:notmuch@notmuchmail.org>\r
  53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  55         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  56 X-List-Received-Date: Tue, 19 Jun 2012 18:52:09 -0000\r
  57 \r
  58 --=-=-=\r
  59 Content-Transfer-Encoding: quoted-printable\r
  60 \r
  61 On Tue, Jun 19 2012, Mark Walters <markwalters1009@gmail.com> wrote:\r
  62 > As you say several tests do need fixing: I\r
  63 > thought I would leave that until people said they were basically happy\r
  64 > with the change.=20\r
  65 \r
  66 Yeah, but failing tests are basically a non-starter for me.  You can\r
  67 maybe get away with not adding new tests during development, but I'm\r
  68 unlikely to even try out the patches if a bunch of the existing tests\r
  69 are failing.\r
  70 \r
  71 > I am not sure about sanity tests for pick: how would that work while it\r
  72 > lives in contrib? Obviously it would need some tests before coming in to\r
  73 > proper mainline.\r
  74 \r
  75 Since you're not actually submitting these patches yet, does it really\r
  76 need to live in contrib?  The goal is for it to ultimately *not* live in\r
  77 contrib, so I would say just go ahead and make them apply in the main\r
  78 source.\r
  79 \r
  80 An example of a sanity test I'm talking about is simply display the pick\r
  81 thread for something and test that it looks like expected.  Sort of a\r
  82 zeroth order thing.  There are other emacs tests that do the same sort\r
  83 of thing so it shouldn't be too hard to add.\r
  84 \r
  85 >> Would it also be useful to make this same change for the search out, for\r
  86 >> consistency?  I notice the search output now uses newlines between all\r
  87 >> fields, which should help for asynchronous processing, but it might be\r
  88 >> nice to put newline separators between the initial and final brackets as\r
  89 >> well.\r
  90 >\r
  91 > Right.=20\r
  92 \r
  93 I would say go ahead and send to the list any patches that come up in\r
  94 development that are generally useful.  Especially if they're small like\r
  95 this they are likely to applied before this series, so it will be\r
  96 smaller and easier to read when the times comes.\r
  97 \r
  98 >> df97df62b70b884a1cd367360ed6ff7eda0e8af6\r
  99 >>     cli: add --headers_only option to notmuch-show.c\r
 100 >>\r
 101 >> Your comment in this patch is very interesting:\r
 102 >>\r
 103 >>     This is used by notmuch-pick.el (although not needed) because it giv=\r
 104 es a\r
 105 >>     speed-up of at least a factor of a two; moreover it reduces the memo=\r
 106 ry\r
 107 >>     usage in emacs hugely.\r
 108 >>\r
 109 >> The only difference between the regular show json output and the\r
 110 >> --headers-only output, as far as I can tell, is the presence of the\r
 111 >> content of text/plain parts if they exist in the message.  We previously\r
 112 >> had a discussion about the show output not including any part bodies at\r
 113 >> all, but we decided that the inclusion of text/plain bodies shouldn't\r
 114 >> affect anything, so why not include them.  If they actually do, then I\r
 115 >> argue we should just move to having show json not include any body parts\r
 116 >> at all by default, and just have them be retrieved individually like we\r
 117 >> do currently for non-text/plain parts.  This would make things cleaner,\r
 118 >> and would get rid of the need to have this extra option, which really\r
 119 >> doesn't produce a significantly different output.\r
 120 >\r
 121 > For one use of pick (displaying the structure of a single thread) this\r
 122 > is not important (and the asynchronous stuff is irrelevant too). For\r
 123 > another use of displaying the thread structure of a whole "folder" of\r
 124 > messages it is important. For example the output of=20\r
 125 >\r
 126 > notmuch show tag:notmuch\r
 127 >\r
 128 > is about 70MB on my system, whereas with the --headers-only option this\r
 129 > drops to about 7MB. Note Emacs uses substantially  more than this much\r
 130 > memory to actually process the JSON, and on a low-powered laptop this\r
 131 > is enough to cause a swap-storm.\r
 132 >\r
 133 > Your suggestion of just not including the text/plain is nice for\r
 134 > notmuch-pick, and is very simple (a single line change). However, it\r
 135 > does seem to slow the emacs show mode down noticeably on large threads\r
 136 > (something like 2s to 4s on a thread with 180 messages) so I worry that\r
 137 > this change might annoy people. What do you think?\r
 138 \r
 139 Threads that long are already a bit of a pain to deal with.  But I think\r
 140 this reveals a weakness in the way we're displaying threads more than\r
 141 anything.  It seems silly to me that we would retrieve all 180 messages\r
 142 From=20such a thread, and format all of them, only to then hide all but\r
 143 the one that the reader is seeing.  I think this "pick" series\r
 144 illustrates this nicely.  Maybe it would be better to refactor the\r
 145 current emacs show mode to only retrieve parts for messages that are\r
 146 being displayed.  I'm not sure how difficult that would be, though.\r
 147 \r
 148 I would also like to have access to more of the message headers in show\r
 149 mode.  For instance, in emacs I want to access more headers with\r
 150 notmuch-message-headers than are currently available.  Having json\r
 151 always include all headers might be a bit of a performance hit for some\r
 152 messages with lots of headers, but it would allow callers access to\r
 153 headers they don't currently have access to at all.\r
 154 \r
 155 So I think it would be nice and clean if the default json output\r
 156 included all the message headers and the message structure, and then\r
 157 part contents could be retrieved individually.  I imagine show mode\r
 158 could be restructured such that it could use this efficiently.\r
 159 \r
 160 jamie.\r
 161 \r
 162 PS. where did the name "pick" come from?  It doesn't seem to fit with\r
 163 the functionality to me.\r
 164 \r
 165 --=-=-=\r
 166 Content-Type: application/pgp-signature\r
 167 \r
 168 -----BEGIN PGP SIGNATURE-----\r
 169 Version: GnuPG v1.4.12 (GNU/Linux)\r
 170 \r
 171 iQIcBAEBCAAGBQJP4MpSAAoJEO00zqvie6q8HWIP/3zuS2RWqZVQyvq7SPhwCtFB\r
 172 9zmWoYvHtTwmeGqgBCAbfVKZVzczSSVW7JIltDL5hT91IDnBY5VT5vifz0fecBz+\r
 173 1U9H0DT5fdU84WB8kzGgvzptHVEbO0QMWodiPRbFjfBk1WovB7EVN1OPfBQE27lw\r
 174 x7okLDEKg0wAXLdFnXC1swoPCxSYVv2Zr+joJwLBmyLBW85Hm+cEmP/ZrMAVrmBe\r
 175 zbl9phzD7XbSudU5UE0sg1AjKfcYbZpeqmgKqdXn38e+0JHQCZsWptBfu/8SDz09\r
 176 9A6+dYSIVKJ8Gv25JkdI9gIKHgh8exc05DH+8KgDEa+L4srpbHpG3DfvedS1WpBy\r
 177 n4xQchF1DXcTk89G228pP0EaNLHR6eF82TqJ2vIfe+csTU0VnaxFsTbXS6Skup1F\r
 178 UvTedyC005el3Ej7quLI43JQa39CktsVT8sEUiqdi9HQpcdmC/PiU/hHdloLjEvS\r
 179 ym1qy45Vfi/hKmoLKVCERmkMVn+i0lkW76m7FVX1oDdM5LjqIYWRDF2JdhP5/whW\r
 180 VT2YCDbwdejKMbB906fZk9tMpvi/ui477gCOYMwf056kJ0iftsj/Jxolc08aHTs5\r
 181 uyRd+5XWdUjCMdGb6NuuxSpoG1B7k7M5iZmSBaKmyDKR+MMPuGUzHBykbehTU4EF\r
 182 R3hVLYoSH5if5SkBFJv5\r
 183 =5XeH\r
 184 -----END PGP SIGNATURE-----\r
 185 --=-=-=--\r