40/16418e0cfd39709b41a7452a9871af01084104

   1 Return-Path: <jani@nikula.org>\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 CFABC431FAF\r
   6         for <notmuch@notmuchmail.org>; Mon,  5 Mar 2012 12:55:57 -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.699\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
  12         tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 MH1XNHoACuj0 for <notmuch@notmuchmail.org>;\r
  16         Mon,  5 Mar 2012 12:55:57 -0800 (PST)\r
  17 Received: from mail-pw0-f53.google.com (mail-pw0-f53.google.com\r
  18         [209.85.160.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id BFEFB431FAE\r
  21         for <notmuch@notmuchmail.org>; Mon,  5 Mar 2012 12:55:56 -0800 (PST)\r
  22 Received: by pbcuo1 with SMTP id uo1so2937889pbc.26\r
  23         for <notmuch@notmuchmail.org>; Mon, 05 Mar 2012 12:55:54 -0800 (PST)\r
  24 Received-SPF: pass (google.com: domain of jani@nikula.org designates\r
  25         10.68.244.99 as permitted sender) client-ip=10.68.244.99; \r
  26 Authentication-Results: mr.google.com;\r
  27         spf=pass (google.com: domain of jani@nikula.org\r
  28         designates 10.68.244.99 as permitted sender)\r
  29         smtp.mail=jani@nikula.org\r
  30 Received: from mr.google.com ([10.68.244.99])\r
  31         by 10.68.244.99 with SMTP id xf3mr31943011pbc.154.1330980954856\r
  32         (num_hops = 1); Mon, 05 Mar 2012 12:55:54 -0800 (PST)\r
  33 MIME-Version: 1.0\r
  34 Received: by 10.68.244.99 with SMTP id xf3mr27794218pbc.154.1330980954646;\r
  35         Mon, 05 Mar 2012 12:55:54 -0800 (PST)\r
  36 Received: by 10.68.12.103 with HTTP; Mon, 5 Mar 2012 12:55:54 -0800 (PST)\r
  37 Received: by 10.68.12.103 with HTTP; Mon, 5 Mar 2012 12:55:54 -0800 (PST)\r
  38 In-Reply-To: <1330613059-5130-2-git-send-email-daniel@schoepe.org>\r
  39 References: <1330613059-5130-1-git-send-email-daniel@schoepe.org>\r
  40         <1330613059-5130-2-git-send-email-daniel@schoepe.org>\r
  41 Date: Mon, 5 Mar 2012 22:55:54 +0200\r
  42 Message-ID:\r
  43  <CAB+hUn-iQbXq_UDcj97h2Duq=gJdxpiJjOn6YzmVcZw+GEgK0A@mail.gmail.com>\r
  44 Subject: Re: [PATCH v2] emacs: Pass a copy to\r
  45         notmuch-saved-search-sort-function\r
  46 From: Jani Nikula <jani@nikula.org>\r
  47 To: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>\r
  48 Content-Type: multipart/alternative; boundary=047d7b33cc1e01282304ba8527e8\r
  49 X-Gm-Message-State:\r
  50  ALoCoQmjdANh73fr7xQuzX0jtrH17qlCe0u0zuScxGQOiJgDzjZRvtxlXGoWfEs0dF1p4aPbyQY1\r
  51 Cc: notmuch@notmuchmail.org\r
  52 X-BeenThere: notmuch@notmuchmail.org\r
  53 X-Mailman-Version: 2.1.13\r
  54 Precedence: list\r
  55 List-Id: "Use and development of the notmuch mail system."\r
  56         <notmuch.notmuchmail.org>\r
  57 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  58         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  59 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  60 List-Post: <mailto:notmuch@notmuchmail.org>\r
  61 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  62 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  63         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  64 X-List-Received-Date: Mon, 05 Mar 2012 20:55:58 -0000\r
  65 \r
  66 --047d7b33cc1e01282304ba8527e8\r
  67 Content-Type: text/plain; charset=UTF-8\r
  68 \r
  69 On Mar 5, 2012 5:43 PM, "Dmitry Kurochkin" <dmitry.kurochkin@gmail.com>\r
  70 wrote:\r
  71 >\r
  72 > On Mon, 05 Mar 2012 12:17:43 +0100, Daniel Schoepe <daniel@schoepe.org>\r
  73 wrote:\r
  74 > > On Mon, 05 Mar 2012 06:21:52 +0400, Dmitry Kurochkin <\r
  75 dmitry.kurochkin@gmail.com> wrote:\r
  76 > > > On Thu,  1 Mar 2012 21:24:38 +0100, Daniel Schoepe <daniel@schoepe.org>\r
  77 wrote:\r
  78 > > > > notmuch-saved-search-sort-function might destructively modify its\r
  79 > > > > input (`sort' does that, for instance), so it should not be given\r
  80 > > > > notmuch-saved-searches directly.\r
  81 > > > > ---\r
  82 > > >\r
  83 > > > -1\r
  84 > > >\r
  85 > > > I think we should require `notmuch-saved-search-sort-function' not to\r
  86 > > > have side effects.  Current documentation should be more clear about\r
  87 > > > this.  We need to fix `notmuch-sort-saved-searches' to copy the list\r
  88 > > > before calling `sort'.  But we should not do it in\r
  89 > > > `notmuch-hello-insert-saved-searches' for any sorting function (which\r
  90 > > > may not need this copying).\r
  91 > >\r
  92 > > My reasoning was that since sort is such a common function, many users\r
  93 > > will probably use sort for their own sorting functions, not realizing\r
  94 > > that it has side effects. This will lead to confusing behavior that's\r
  95 > > not so easy to track down.\r
  96 > >\r
  97 > > Copying the list of saved searches when running notmuch-hello does not\r
  98 > > seem be relevant to performance to me, since it's a) not called that\r
  99 > > often and b) the list of saved searches will rarely exceed 30 elements.\r
 100 > >\r
 101 > > Hence, this way we can avoid some headaches for users who define their\r
 102 > > own sorting functions at a negligible (performance) cost. Incidentally,\r
 103 > > this is also how notmuch-hello did it before the user-defined sections\r
 104 > > patches.\r
 105 > >\r
 106 >\r
 107 > I do not buy the argument that we should help users who implement their\r
 108 > own sorting functions but do not read documentation for functions they\r
 109 > use.  Apparently, those who implemented the `sort' function had similar\r
 110 > ideas.  And I do not think it is our job to add workarounds for it.\r
 111 >\r
 112 > An alternative (and IMO better) solution would be to allow customization\r
 113 > of compare function used for sorting instead of the sorting function\r
 114 > itself.\r
 115 \r
 116 Providing the customization of the sort function is more powerful than the\r
 117 compare function. In the case of saved searches I can imagine people might\r
 118 want to partially use the original order while sort the rest (e.g.\r
 119 important ones first in predefined order, others sorted). In fact this also\r
 120 allows dropping out some elements. And renaming. And changing the queries...\r
 121 \r
 122 (I had something like that in mind originally but then settled with just\r
 123 capitalizing the important ones to show them first.)\r
 124 \r
 125 BR,\r
 126 Jani.\r
 127 \r
 128 >\r
 129 > Regards,\r
 130 >  Dmitry\r
 131 >\r
 132 > > Cheers,\r
 133 > > Daniel\r
 134 > _______________________________________________\r
 135 > notmuch mailing list\r
 136 > notmuch@notmuchmail.org\r
 137 > http://notmuchmail.org/mailman/listinfo/notmuch\r
 138 \r
 139 --047d7b33cc1e01282304ba8527e8\r
 140 Content-Type: text/html; charset=UTF-8\r
 141 Content-Transfer-Encoding: quoted-printable\r
 142 \r
 143 <p><br>\r
 144 On Mar 5, 2012 5:43 PM, &quot;Dmitry Kurochkin&quot; &lt;<a href=3D"mailto:=\r
 145 dmitry.kurochkin@gmail.com">dmitry.kurochkin@gmail.com</a>&gt; wrote:<br>\r
 146 &gt;<br>\r
 147 &gt; On Mon, 05 Mar 2012 12:17:43 +0100, Daniel Schoepe &lt;<a href=3D"mail=\r
 148 to:daniel@schoepe.org">daniel@schoepe.org</a>&gt; wrote:<br>\r
 149 &gt; &gt; On Mon, 05 Mar 2012 06:21:52 +0400, Dmitry Kurochkin &lt;<a href=\r
 150 =3D"mailto:dmitry.kurochkin@gmail.com">dmitry.kurochkin@gmail.com</a>&gt; w=\r
 151 rote:<br>\r
 152 &gt; &gt; &gt; On Thu, =C2=A01 Mar 2012 21:24:38 +0100, Daniel Schoepe &lt;=\r
 153 <a href=3D"mailto:daniel@schoepe.org">daniel@schoepe.org</a>&gt; wrote:<br>\r
 154 &gt; &gt; &gt; &gt; notmuch-saved-search-sort-function might destructively =\r
 155 modify its<br>\r
 156 &gt; &gt; &gt; &gt; input (`sort&#39; does that, for instance), so it shoul=\r
 157 d not be given<br>\r
 158 &gt; &gt; &gt; &gt; notmuch-saved-searches directly.<br>\r
 159 &gt; &gt; &gt; &gt; ---<br>\r
 160 &gt; &gt; &gt;<br>\r
 161 &gt; &gt; &gt; -1<br>\r
 162 &gt; &gt; &gt;<br>\r
 163 &gt; &gt; &gt; I think we should require `notmuch-saved-search-sort-functio=\r
 164 n&#39; not to<br>\r
 165 &gt; &gt; &gt; have side effects. =C2=A0Current documentation should be mor=\r
 166 e clear about<br>\r
 167 &gt; &gt; &gt; this. =C2=A0We need to fix `notmuch-sort-saved-searches&#39;=\r
 168  to copy the list<br>\r
 169 &gt; &gt; &gt; before calling `sort&#39;. =C2=A0But we should not do it in<=\r
 170 br>\r
 171 &gt; &gt; &gt; `notmuch-hello-insert-saved-searches&#39; for any sorting fu=\r
 172 nction (which<br>\r
 173 &gt; &gt; &gt; may not need this copying).<br>\r
 174 &gt; &gt;<br>\r
 175 &gt; &gt; My reasoning was that since sort is such a common function, many =\r
 176 users<br>\r
 177 &gt; &gt; will probably use sort for their own sorting functions, not reali=\r
 178 zing<br>\r
 179 &gt; &gt; that it has side effects. This will lead to confusing behavior th=\r
 180 at&#39;s<br>\r
 181 &gt; &gt; not so easy to track down.<br>\r
 182 &gt; &gt;<br>\r
 183 &gt; &gt; Copying the list of saved searches when running notmuch-hello doe=\r
 184 s not<br>\r
 185 &gt; &gt; seem be relevant to performance to me, since it&#39;s a) not call=\r
 186 ed that<br>\r
 187 &gt; &gt; often and b) the list of saved searches will rarely exceed 30 ele=\r
 188 ments.<br>\r
 189 &gt; &gt;<br>\r
 190 &gt; &gt; Hence, this way we can avoid some headaches for users who define =\r
 191 their<br>\r
 192 &gt; &gt; own sorting functions at a negligible (performance) cost. Inciden=\r
 193 tally,<br>\r
 194 &gt; &gt; this is also how notmuch-hello did it before the user-defined sec=\r
 195 tions<br>\r
 196 &gt; &gt; patches.<br>\r
 197 &gt; &gt;<br>\r
 198 &gt;<br>\r
 199 &gt; I do not buy the argument that we should help users who implement thei=\r
 200 r<br>\r
 201 &gt; own sorting functions but do not read documentation for functions they=\r
 202 <br>\r
 203 &gt; use. =C2=A0Apparently, those who implemented the `sort&#39; function h=\r
 204 ad similar<br>\r
 205 &gt; ideas. =C2=A0And I do not think it is our job to add workarounds for i=\r
 206 t.<br>\r
 207 &gt;<br>\r
 208 &gt; An alternative (and IMO better) solution would be to allow customizati=\r
 209 on<br>\r
 210 &gt; of compare function used for sorting instead of the sorting function<b=\r
 211 r>\r
 212 &gt; itself.</p>\r
 213 <p>Providing the customization of the sort function is more powerful than t=\r
 214 he compare function. In the case of saved searches I can imagine people mig=\r
 215 ht want to partially use the original order while sort the rest (e.g. impor=\r
 216 tant ones first in predefined order, others sorted). In fact this also allo=\r
 217 ws dropping out some elements. And renaming. And changing the queries...</p=\r
 218 >\r
 219 \r
 220 <p>(I had something like that in mind originally but then settled with just=\r
 221  capitalizing the important ones to show them first.)</p>\r
 222 <p>BR,<br>\r
 223 Jani.</p>\r
 224 <p>&gt;<br>\r
 225 &gt; Regards,<br>\r
 226 &gt; =C2=A0Dmitry<br>\r
 227 &gt;<br>\r
 228 &gt; &gt; Cheers,<br>\r
 229 &gt; &gt; Daniel<br>\r
 230 &gt; _______________________________________________<br>\r
 231 &gt; notmuch mailing list<br>\r
 232 &gt; <a href=3D"mailto:notmuch@notmuchmail.org">notmuch@notmuchmail.org</a>=\r
 233 <br>\r
 234 &gt; <a href=3D"http://notmuchmail.org/mailman/listinfo/notmuch">http://not=\r
 235 muchmail.org/mailman/listinfo/notmuch</a><br>\r
 236 </p>\r
 237 \r
 238 --047d7b33cc1e01282304ba8527e8--\r