51/fbc7c04f32de168349efa01320b80f3d3a2e4c

   1 Return-Path: <cworth@cworth.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 E06E34196F3\r
   6         for <notmuch@notmuchmail.org>; Fri, 23 Apr 2010 12:44:01 -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.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=ham\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id WYLKvKtJ0Jxn; Fri, 23 Apr 2010 12:44:01 -0700 (PDT)\r
  17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id F24E8431FC1;\r
  19         Fri, 23 Apr 2010 12:44:00 -0700 (PDT)\r
  20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  21         id A21E4568DE4; Fri, 23 Apr 2010 12:44:00 -0700 (PDT)\r
  22 From: Carl Worth <cworth@cworth.org>\r
  23 To: David Edmondson <dme@dme.org>, notmuch <notmuch@notmuchmail.org>\r
  24 Subject: Re: pull request\r
  25 In-Reply-To: <87tyr4j7l3.fsf@ut.hh.sledj.net>\r
  26 References: <87sk722sfq.fsf@ut.hh.sledj.net> <87eiibq22s.fsf@ut.hh.sledj.net>\r
  27         <87iq7kjz7c.fsf@yoom.home.cworth.org>\r
  28         <87tyr4j7l3.fsf@ut.hh.sledj.net>\r
  29 Date: Fri, 23 Apr 2010 12:44:00 -0700\r
  30 Message-ID: <871ve6gdj3.fsf@yoom.home.cworth.org>\r
  31 MIME-Version: 1.0\r
  32 Content-Type: multipart/signed; boundary="=-=-=";\r
  33         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  34 X-BeenThere: notmuch@notmuchmail.org\r
  35 X-Mailman-Version: 2.1.13\r
  36 Precedence: list\r
  37 List-Id: "Use and development of the notmuch mail system."\r
  38         <notmuch.notmuchmail.org>\r
  39 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  40         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  41 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  42 List-Post: <mailto:notmuch@notmuchmail.org>\r
  43 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  44 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  46 X-List-Received-Date: Fri, 23 Apr 2010 19:44:02 -0000\r
  47 \r
  48 --=-=-=\r
  49 \r
  50 On Thu, 22 Apr 2010 07:59:36 +0100, David Edmondson <dme@dme.org> wrote:\r
  51 > Your concerns appear to be about `notmuch-wash-wrap-long-lines'. I agree\r
  52 > that it can generate unfortunate results in the "deep thread, narrow\r
  53 > terminal" case. Are the other two functions okay?\r
  54 \r
  55 If they had come in as separate patches, I would have reviewed them\r
  56 separately and would have applied any I was OK with.\r
  57 \r
  58 I'm not sure about the other two, as I really haven't played with\r
  59 them. I don't think I'd get a lot of benefit from them as I don't recall\r
  60 seeing a lot of accidental duplicate lines anywhere.\r
  61 \r
  62 I still do have some concerns about munging the original message,\r
  63 though. I can easily imagine that suppressing duplicate blank lines\r
  64 could destroy some ASCII (or UTF-8!) art for example.\r
  65 \r
  66 So I think things that do this kind of munging really should be on an\r
  67 opt-in basis.\r
  68 \r
  69 > One of the reasons that I chose a hook-based approach is to allow the\r
  70 > user to decide which body cleaning should be applied. If you don't want\r
  71 > the line-wrapping to be enabled by default we can leave it out but\r
  72 > include the definition so that a user can enable it. The inline-patch\r
  73 > formatting is similar (I'll say more about that in response to your\r
  74 > comments on it).\r
  75 \r
  76 I do appreciate the way the hook works such that users can select which\r
  77 ones they want. Let's make all of these available but any that could\r
  78 possibly "corrupt" a message be off by default. And let's be sure to\r
  79 find a way to easily advertise the list of available washing functions\r
  80 to the user, (perhaps in the documentation of the customize option for\r
  81 this).\r
  82 \r
  83 > Aside from the need to test, this particular patch will benefit only\r
  84 > minimally from testing - there will always be false positive cases\r
  85 > however good the analysis used. Are you saying that we can not tolerate\r
  86 > any false-positives, or that we just need to demonstrate that it is down\r
  87 > to some acceptable level? (Though I've no idea how I would achieve the\r
  88 > latter.)\r
  89 \r
  90 I may have overreacted to a misreading of the commit message. I read it\r
  91 almost like "Here's some code that is known to be buggy" which is\r
  92 something I don't ever want to accept. If the meaning is instead, "some\r
  93 users might find this handy while others find it unacceptable", then\r
  94 that would be more acceptable.\r
  95 \r
  96 I think it would be useful to define exactly what the implemented\r
  97 conditions are so that users can easily decide whether they trust the\r
  98 heuristic.\r
  99 \r
 100 (Personally, even when correctly identified, the coloring of patch\r
 101 output is distracting to me.)\r
 102 \r
 103 The remainder of the discussion about future improvements to mime part\r
 104 handling and, multipart support, and HTML rendering is all very\r
 105 encouraging. I look forward to the future!\r
 106 \r
 107 -Carl\r
 108 \r
 109 --=-=-=\r
 110 Content-Type: application/pgp-signature\r
 111 \r
 112 -----BEGIN PGP SIGNATURE-----\r
 113 Version: GnuPG v1.4.10 (GNU/Linux)\r
 114 \r
 115 iD8DBQFL0fiA6JDdNq8qSWgRAt8MAKCcQYagEWBtOTzfHCtnxPxJ68YlpgCgnQj+\r
 116 n22t8vFI1BnMghTqFpZE/gw=\r
 117 =Eyr9\r
 118 -----END PGP SIGNATURE-----\r
 119 --=-=-=--\r