22/6a61bfba2120132928f1ab8ef246fbb32463d5

   1 Return-Path: <awg@xvx.ca>\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 D7436431FAF\r
   6         for <notmuch@notmuchmail.org>; Sun,  5 Feb 2012 11:42:14 -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.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 4BN5S62w0cYg for <notmuch@notmuchmail.org>;\r
  16         Sun,  5 Feb 2012 11:42:14 -0800 (PST)\r
  17 Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com\r
  18         [209.85.214.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 231C5431FAE\r
  21         for <notmuch@notmuchmail.org>; Sun,  5 Feb 2012 11:42:14 -0800 (PST)\r
  22 Received: by bke11 with SMTP id 11so4921842bke.26\r
  23         for <notmuch@notmuchmail.org>; Sun, 05 Feb 2012 11:42:12 -0800 (PST)\r
  24 MIME-Version: 1.0\r
  25 Received: by 10.204.152.88 with SMTP id f24mr6988544bkw.31.1328470932637; Sun,\r
  26         05 Feb 2012 11:42:12 -0800 (PST)\r
  27 Sender: awg@xvx.ca\r
  28 Received: by 10.204.104.13 with HTTP; Sun, 5 Feb 2012 11:42:12 -0800 (PST)\r
  29 X-Originating-IP: [96.52.216.56]\r
  30 In-Reply-To: <87mx8xpki3.fsf@qmul.ac.uk>\r
  31 References: <1326995217-27423-1-git-send-email-awg+notmuch@xvx.ca>\r
  32         <1326995217-27423-3-git-send-email-awg+notmuch@xvx.ca>\r
  33         <87mx8xpki3.fsf@qmul.ac.uk>\r
  34 Date: Sun, 5 Feb 2012 12:42:12 -0700\r
  35 X-Google-Sender-Auth: HZo5Bc1rP1ZkylxqA2wJAh7fj9w\r
  36 Message-ID:\r
  37  <CAMoJFUusrzG9GcAwrbK0iNDaUOCVsc=e-i-n0tEcSOSF4XBn0Q@mail.gmail.com>\r
  38 Subject: Re: [PATCH v3 2/5] reply: Add a JSON reply format.\r
  39 From: Adam Wolfe Gordon <awg+notmuch@xvx.ca>\r
  40 To: Mark Walters <markwalters1009@gmail.com>\r
  41 Content-Type: text/plain; charset=ISO-8859-1\r
  42 Content-Transfer-Encoding: quoted-printable\r
  43 Cc: notmuch@notmuchmail.org\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: Sun, 05 Feb 2012 19:42:15 -0000\r
  57 \r
  58 Thanks for the review. The style nits are things I missed in my\r
  59 previous cleanup, so thanks for pointing them out. I should probably\r
  60 run uncrustify and see if it complains about anything else.\r
  61 \r
  62 The other points are definitely up for discussion, and some are areas\r
  63 where I was unsure to start with. Discussion inline:\r
  64 \r
  65 On Sun, Feb 5, 2012 at 04:50, Mark Walters <markwalters1009@gmail.com> wrot=\r
  66 e:\r
  67 >> + =A0 =A0/* We only care about inline text parts for reply purposes */\r
  68 >> + =A0 =A0if (reply_check_part_type (part, "text", "*", GMIME_DISPOSITION=\r
  69 _INLINE)) {\r
  70 >\r
  71 > This seems to be different from the logic in the text output: I think\r
  72 > that inlines all text/* regardless of disposition. I think the JSON\r
  73 > output should include at least as much as the text output as it is easy\r
  74 > for the caller to discard parts.\r
  75 \r
  76 Indeed, the text output includes all text/* parts except for\r
  77 text/html, regardless of disposition. My thought was that it doesn't\r
  78 really make sense to quote an attachment, or at least it's not the\r
  79 behavior I would expect. But, perhaps it makes more sense to include\r
  80 all the text parts, with their dispositions, and let the MUA decide\r
  81 what it wants to quote. If anyone has thoughts on this I'm happy to\r
  82 hear them.\r
  83 \r
  84 > Does wrapper need to a free/unref somewhere?\r
  85 \r
  86 The text format doesn't free or unref wrapper, so I followed its\r
  87 example. But, I'm not a gmime expert, and I agree intuitively that it\r
  88 should be freed somehow. Can anyone enlighten me?\r
  89 \r
  90 > If replying to multiple messages (such as a whole thread) you get\r
  91 > multiple sets of "new headers". I think that probably is not what is\r
  92 > wanted but its still better than the weird things the text version\r
  93 > does. Might be worth putting a comment. [What I think should happen is\r
  94 > that a union of all the headers from all these is taken throwing away\r
  95 > duplicate addresses but that is obviously not part of this patch set]\r
  96 \r
  97 I've never been sure about what the intended behavior is when replying\r
  98 to multiple messages in the CLI. My thought was that it should create\r
  99 a reply to each message, so an MUA could iterate over them allowing\r
 100 you to compose replies to multiple messages. But, I've never wanted or\r
 101 used such a feature, so I'm agnostic on whether it's right. The emacs\r
 102 MUA (at least with my patch) ignores all but the first reply object in\r
 103 the array, my assumption being that reply only operates on multiple\r
 104 messages by accident.\r
 105 \r
 106 Does anyone use reply with multiple messages? If so, what semantics do\r
 107 you expect?\r