21/4b204e872abc7e7f4ae20117db910d394627d6

   1 Return-Path: <dme@dme.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 1D4C0431FBD\r
   6         for <notmuch@notmuchmail.org>; Tue, 13 May 2014 03:07: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: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[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 Z2i0yYmXzf08 for <notmuch@notmuchmail.org>;\r
  16         Tue, 13 May 2014 03:07:01 -0700 (PDT)\r
  17 Received: from mail-we0-f173.google.com (mail-we0-f173.google.com\r
  18         [74.125.82.173]) (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 E48F6431FAF\r
  21         for <notmuch@notmuchmail.org>; Tue, 13 May 2014 03:07:00 -0700 (PDT)\r
  22 Received: by mail-we0-f173.google.com with SMTP id u57so123503wes.32\r
  23         for <notmuch@notmuchmail.org>; Tue, 13 May 2014 03:06:59 -0700 (PDT)\r
  24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
  25         d=1e100.net; s=20130820;\r
  26         h=x-gm-message-state:to:subject:in-reply-to:references:user-agent\r
  27         :from:date:message-id:mime-version:content-type;\r
  28         bh=UZUrSSUDZlB4J7j0QRMSG7LqpZVHQhH569M81j9ignA=;\r
  29         b=UPwqg3U0DRIO5VaV3enbNcL0hHXfjC988J8e1jlwBep9L9XWFEEQazgdDB5npPnjUa\r
  30         rkmTY4OYsGI378BpLfc/QU1q33NEakdiY64takddHvJQYBtJhFz2Xqd9ERW4Qnxu2G+c\r
  31         M+AZYJzbEtRqrbHOVNvxAZ18m0J069uXyHVD3r/69nP+aQxJ/WubwnT5VDKwHv4wjVIf\r
  32         pvhE7vISqRTZVOVZ8Ao3f4Ksb72oTERMS2dYpyTmfVNHZs8mvRp0mA/Ot2NUbH3Gsh/h\r
  33         IkHBxkCg+gNGWIxPNJ5I6dL91ARAeNiu8iiT7oeL+8grTzsmBoAj/NN7F5ebtdVGYNKb\r
  34         K44A==\r
  35 X-Gm-Message-State:\r
  36  ALoCoQk5Eec3J5ryKiOzLroFUPL/GWnvOFlr/QFSCxGZVu9EpNq8Vl6soSDSO88TlsI1GLE+4yuz\r
  37 X-Received: by 10.194.84.101 with SMTP id x5mr2264080wjy.52.1399975619774;\r
  38         Tue, 13 May 2014 03:06:59 -0700 (PDT)\r
  39 Received: from localhost ([2a01:348:1a2:1:a288:b4ff:fe8a:77d8])\r
  40         by mx.google.com with ESMTPSA id fi2sm21077084wib.2.2014.05.13.03.06.58\r
  41         for <multiple recipients>\r
  42         (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\r
  43         Tue, 13 May 2014 03:06:58 -0700 (PDT)\r
  44 To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org\r
  45 Subject: Re: [PATCH v3 4/9] emacs/mua: Generate improved cited text for\r
  46  replies\r
  47 In-Reply-To: <87egzyk4u2.fsf@qmul.ac.uk>\r
  48 References: <87sixdujkv.fsf@qmul.ac.uk>\r
  49         <1399897769-26809-1-git-send-email-dme@dme.org>\r
  50         <1399897769-26809-5-git-send-email-dme@dme.org>\r
  51         <87egzyk4u2.fsf@qmul.ac.uk>\r
  52 User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.1\r
  53         (x86_64-pc-linux-gnu)\r
  54 From: David Edmondson <dme@dme.org>\r
  55 Date: Tue, 13 May 2014 11:06:53 +0100\r
  56 Message-ID: <cunr43y56wy.fsf@hotblack-desiato.hh.sledj.net>\r
  57 MIME-Version: 1.0\r
  58 Content-Type: multipart/signed; boundary="=-=-=";\r
  59         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  60 X-BeenThere: notmuch@notmuchmail.org\r
  61 X-Mailman-Version: 2.1.13\r
  62 Precedence: list\r
  63 List-Id: "Use and development of the notmuch mail system."\r
  64         <notmuch.notmuchmail.org>\r
  65 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  66         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  67 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  68 List-Post: <mailto:notmuch@notmuchmail.org>\r
  69 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  70 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  71         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  72 X-List-Received-Date: Tue, 13 May 2014 10:07:09 -0000\r
  73 \r
  74 --=-=-=\r
  75 Content-Type: text/plain\r
  76 \r
  77 On Mon, May 12 2014, Mark Walters wrote:\r
  78 > On Mon, 12 May 2014, David Edmondson <dme@dme.org> wrote:\r
  79 >> Use the message display code to generate message text to cite in\r
  80 >> replies.\r
  81 >\r
  82 > So this is the key change. I am trying to work out what the actual\r
  83 > changes are here: in your commit message for the test update 7/9 you say\r
  84 > that the old code only output the first part. My impression of the\r
  85 > deleted code is that that is not the case (but I don't grok cl very\r
  86 > well).\r
  87 \r
  88 The comment in the test change was intended only to refer to the content\r
  89 displayed in that specific test. You are correct that text from several\r
  90 parts could previously have been used (and all smashed together in a way\r
  91 that made it difficult to see the boundaries between the parts...).\r
  92 \r
  93 > I think the test change is because in show we do some content-type\r
  94 > guessing of application/octet-stream which the below doesn't do.\r
  95 >\r
  96 > But we may also have some things with mm-inlined-types as mentioned in\r
  97 > my earlier reply. Anyway if you can point out any other cases where it\r
  98 > is changed that would be great.\r
  99 \r
 100 message/rfc822 was the initial driver. If you now reply to a\r
 101 multipart/mixed that contains text/plain and message/rfc822 parts, you\r
 102 will see a significant difference.\r
 103 \r
 104 I'm not sure if you have it, but\r
 105 id:mailman.1.1399324386.31850.notmuch@notmuchmail.org was the message I\r
 106 used often when playing around.\r
 107 \r
 108 > If you go for a function deciding which parts to include then it might\r
 109 > be possible to have a midpoint where we are the same as before, and then\r
 110 > tweak the function to get whatever behaviour we think is best. That\r
 111 > might make it easy to see what is tidying/unification and what is\r
 112 > enhancement.\r
 113 \r
 114 I will look into that - it's a good suggestion, though it actually runs\r
 115 counter to:\r
 116 \r
 117 > Incidentally, thank you for splitting this series so finely: I did find\r
 118 > that made it a lot easier to review.\r
 119 \r
 120 Making the new code (which relies on the 'show' rendering code) behave\r
 121 just like the old code will involve adding a bunch of complication to\r
 122 this specific patch.\r
 123 \r
 124 --=-=-=\r
 125 Content-Type: application/pgp-signature; name="signature.asc"\r
 126 \r
 127 -----BEGIN PGP SIGNATURE-----\r
 128 Version: GnuPG v1\r
 129 \r
 130 iKYEARECAGYFAlNx7r1fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl\r
 131 bnBncC5maWZ0aGhvcnNlbWFuLm5ldDc1M0Y5NDJDMEExNjc3MDE4OURGMUYyMDY5\r
 132 RUNEMEFCRjA0OTY1MTYACgkQaezQq/BJZRYfGACfWo7Sw394a9dEXVGFYVhT3Iw0\r
 133 pf0An3NpM1lAemnMdty6v/85b4ocRkFc\r
 134 =QXWj\r
 135 -----END PGP SIGNATURE-----\r
 136 --=-=-=--\r