c7/cf1430b3ddde896a857ce1a6e071947314c57f

   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 7F509431FB6\r
   6         for <notmuch@notmuchmail.org>; Sun, 20 May 2012 08:34:56 -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 qYJUBtrE5ElG for <notmuch@notmuchmail.org>;\r
  16         Sun, 20 May 2012 08:34:54 -0700 (PDT)\r
  17 Received: from mail-lpp01m010-f53.google.com (mail-lpp01m010-f53.google.com\r
  18         [209.85.215.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 978E8431FAE\r
  21         for <notmuch@notmuchmail.org>; Sun, 20 May 2012 08:34:54 -0700 (PDT)\r
  22 Received: by lagu2 with SMTP id u2so3478750lag.26\r
  23         for <notmuch@notmuchmail.org>; Sun, 20 May 2012 08:34:51 -0700 (PDT)\r
  24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
  25         d=google.com; s=20120113;\r
  26         h=mime-version:sender:x-originating-ip:in-reply-to:references:date\r
  27         :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
  28         :content-transfer-encoding:x-gm-message-state;\r
  29         bh=tEWgpW06KE7GKjpnHkKqwR6tdvV5SURNuhRR+Ip755g=;\r
  30         b=mWdfREXlujHWx4OqhubSvZ9qyPDwn8N3AFiGx0otsmKvO/gnTqNK53tRppjyf+QcbJ\r
  31         2UvciQtw15+LKACSrk8PA55RcC29LStdySLI5VCDu46jBb7ZwaFiZ3wYJmKP6aB2KDES\r
  32         ZANG+nqZvkvqSVMmOpa/5O2qMxIhgeW2hQipfIYiSXWu/qVZLBAnn13ax2+hVL7/Oj3U\r
  33         WCiIjAj2DySaird7ecNywVZpycOtylGFjBCuv39Ei/n9NHA8pne6enSyxh93CwUoxvTM\r
  34         Iazjcxe+oO0Pdskz+DnjJUHNY1TxldTvmhgA28NJIsfGYWlBXNnkP8MgmolpeAt/1egS\r
  35         G2dQ==\r
  36 MIME-Version: 1.0\r
  37 Received: by 10.152.145.41 with SMTP id sr9mr10681666lab.25.1337528091518;\r
  38         Sun, 20 May 2012 08:34:51 -0700 (PDT)\r
  39 Sender: awg@xvx.ca\r
  40 Received: by 10.112.82.163 with HTTP; Sun, 20 May 2012 08:34:51 -0700 (PDT)\r
  41 X-Originating-IP: [96.52.216.56]\r
  42 In-Reply-To: <m23970bhre.fsf@guru.guru-group.fi>\r
  43 References: <20120515194455.B7AD5100646@guru.guru-group.fi>\r
  44         <878vgsbprq.fsf@nikula.org> <m23970bhre.fsf@guru.guru-group.fi>\r
  45 Date: Sun, 20 May 2012 09:34:51 -0600\r
  46 X-Google-Sender-Auth: 92fN3P7EpdBUqCWr4e1SsCOyQ-M\r
  47 Message-ID:\r
  48  <CAMoJFUungAFPWy0d1Lh+rqmpK--P7MMEwNaewWHR=rbYo+BKsA@mail.gmail.com>\r
  49 Subject: Re: emacs complains about encoding?\r
  50 From: Adam Wolfe Gordon <awg+notmuch@xvx.ca>\r
  51 To: Tomi Ollila <tomi.ollila@iki.fi>\r
  52 Content-Type: text/plain; charset=ISO-8859-1\r
  53 Content-Transfer-Encoding: quoted-printable\r
  54 X-Gm-Message-State:\r
  55  ALoCoQnZSxpxAMqJqUbF4AsRCO4a+i0bJBP47PyxcuUvQUIOciwUWyMlj/Lv7JR4HFwQkzhoFtyv\r
  56 Cc: notmuch@notmuchmail.org\r
  57 X-BeenThere: notmuch@notmuchmail.org\r
  58 X-Mailman-Version: 2.1.13\r
  59 Precedence: list\r
  60 List-Id: "Use and development of the notmuch mail system."\r
  61         <notmuch.notmuchmail.org>\r
  62 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  63         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  64 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  65 List-Post: <mailto:notmuch@notmuchmail.org>\r
  66 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  67 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  68         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  69 X-List-Received-Date: Sun, 20 May 2012 15:34:56 -0000\r
  70 \r
  71 On Wed, May 16, 2012 at 3:24 AM, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
  72 > Haa, It doesn't matter which is the original encoding of the message;\r
  73 >\r
  74 > notmuch reply id:20120515194455.B7AD5100646@guru.guru-group.fi\r
  75 >\r
  76 > where =A0notmuch show --format=3Draw ^^^ =A0outputs (among other lines):\r
  77 >\r
  78 > =A0Content-Type: text/plain; charset=3D"iso-8859-1"\r
  79 > =A0Content-Transfer-Encoding: quoted-printable\r
  80 >\r
  81 > and\r
  82 >\r
  83 > notmuch reply id:"878vgsbprq.fsf@nikula.org"\r
  84 >\r
  85 > where =A0notmuch show --format=3Draw ^^^ =A0outputs (among other lines):\r
  86 >\r
  87 > =A0Content-Type: text/plain; charset=3D"utf-8"\r
  88 > =A0Content-Transfer-Encoding: base64\r
  89 >\r
  90 > produce correct reply content, both in utf-8.\r
  91 >\r
  92 > So it is the emacs side which breaks replies.\r
  93 \r
  94 It turns out it's actually not the emacs side, but an interaction\r
  95 between our JSON reply format and emacs.\r
  96 \r
  97 The JSON reply (and show) code includes part content for all text/*\r
  98 parts except text/html. Because all JSON is required to be UTF-8, it\r
  99 handles the encoding itself, puts UTF-8 text in, and omits a\r
 100 content-charset field from the output. Emacs passes on the\r
 101 content-charset field to mm-display-part-inline if it's available, but\r
 102 for text/plain parts it's not, leaving mm-display-part-inline to its\r
 103 own devices for figuring out what the charset is. It seems\r
 104 mm-display-part-inline correctly figures out that it's UTF-8, and puts\r
 105 in the series of ugly \nnn characters because that's what emacs does\r
 106 with UTF-8 sometimes.\r
 107 \r
 108 In the original reply stuff (pre-JSON reply format) emacs used the\r
 109 output of notmuch reply verbatim, so all the charset stuff was handled\r
 110 in notmuch. Before f6c170fabca8f39e74705e3813504137811bf162, emacs was\r
 111 using the JSON reply format, but was inserting the text itself instead\r
 112 of using mm-display-part-inline, so emacs still wasn't trying to do\r
 113 any charset manipulation. Using mm-display-part-inline is desirable\r
 114 because it lets us handle non-text/plain (e.g. text/html) parts\r
 115 correctly in reply, and makes the display more consistent (since we\r
 116 use it for show). But, it leads to this problem.\r
 117 \r
 118 So, there are a couple of solutions I can see:\r
 119 \r
 120 1) Have the JSON formats include the original content-charset even\r
 121 though they're actually outputting UTF-8. Of the solutions I tried,\r
 122 this is the best, even though it doesn't sound like a good thing to\r
 123 do.\r
 124 \r
 125 2) Have the JSON formats include content only if it's actually UTF-8.\r
 126 This means that for non-UTF-8 parts (including ASCII parts), the emacs\r
 127 interface has to do more work to display the part content, since it\r
 128 must fetch it from outside first. When I tried this, it worked but\r
 129 caused the \nnn to show up when viewing messages in emacs. I suspect\r
 130 this is because it sets a charset for the whole buffer, and can't\r
 131 accommodate messages with different charsets in the same buffer\r
 132 properly. Reply works correctly, though.\r
 133 \r
 134 3) Have the JSON formats include the charset for all parts, but make\r
 135 it UTF-8 for all parts they include content for (since we're actually\r
 136 outputting UTF-8). This doesn't seem to fix the problem, even though\r
 137 it seems like it should.\r
 138 \r
 139 If no one has a better idea or a strong reason not to, I'll send a\r
 140 patch for solution (1).\r
 141 \r
 142 -- Adam\r