Re: [BUG] Saving attachments containing UTF-8 chars
authorEthan Glasser-Camp <ethan.glasser.camp@gmail.com>
Sun, 18 Nov 2012 05:29:31 +0000 (00:29 +1900)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:50:39 +0000 (09:50 -0800)
ea/10545104fb0e4f0eaa9a2ad6c23b4480422c89 [new file with mode: 0644]

diff --git a/ea/10545104fb0e4f0eaa9a2ad6c23b4480422c89 b/ea/10545104fb0e4f0eaa9a2ad6c23b4480422c89
new file mode 100644 (file)
index 0000000..96164d9
--- /dev/null
@@ -0,0 +1,136 @@
+Return-Path: <ethan.glasser.camp@gmail.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id AED04431FAF\r
+       for <notmuch@notmuchmail.org>; Sat, 17 Nov 2012 21:29:37 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 1.7\r
+X-Spam-Level: *\r
+X-Spam-Status: No, score=1.7 tagged_above=-999 required=5\r
+       tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+       FREEMAIL_FROM=0.001, FREEMAIL_REPLY=2.499, RCVD_IN_DNSWL_LOW=-0.7]\r
+       autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id c-DuE+xgLewG for <notmuch@notmuchmail.org>;\r
+       Sat, 17 Nov 2012 21:29:36 -0800 (PST)\r
+Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com\r
+       [209.85.216.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 963A7431FAE\r
+       for <notmuch@notmuchmail.org>; Sat, 17 Nov 2012 21:29:36 -0800 (PST)\r
+Received: by mail-qa0-f46.google.com with SMTP id c11so4919206qad.5\r
+       for <notmuch@notmuchmail.org>; Sat, 17 Nov 2012 21:29:36 -0800 (PST)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
+       h=from:to:subject:in-reply-to:references:user-agent:date:message-id\r
+       :mime-version:content-type;\r
+       bh=5SyJn52b3ILvGjmTDka1q2VrY7pb+68yyMaU5hgGDF8=;\r
+       b=jF8RpRQXpDxXA1qzMX+S4kn0Jo58b/gojeMbsnxOkXgNBWbS8RcZpDk5sj98vrFcie\r
+       qQva+w/oaKIO6SS48RUSopfxHu4Vyo9l3VCF8TswmF+Ml1utjVe+aSq917WvxZKoA09Q\r
+       tiDZmujFKMsFF/LS6phYzKm0boQxiR1PcYtyRZcsqwLqwQk1A1KAyeS995y9fSZdUUsV\r
+       CmE/mkeYxTBKr1ABmlk7GNiZKmzCPhgMJ6vMxYQEFEC5C0nehHrGQ965J/HKoHdk81m5\r
+       3b6V6i0skiML73rwvHh9WMhY6jduIS9h+jbtOiZRd1VhNdOAl3r2XucgcjR7+siGokTR\r
+       G3/Q==\r
+Received: by 10.49.24.163 with SMTP id v3mr9571296qef.48.1353216576087;\r
+       Sat, 17 Nov 2012 21:29:36 -0800 (PST)\r
+Received: from smtp.gmail.com ([66.114.71.21])\r
+       by mx.google.com with ESMTPS id ho6sm3479195qeb.3.2012.11.17.21.29.33\r
+       (version=TLSv1/SSLv3 cipher=OTHER);\r
+       Sat, 17 Nov 2012 21:29:33 -0800 (PST)\r
+From: Ethan Glasser-Camp <ethan.glasser.camp@gmail.com>\r
+To: Tomi Ollila <tomi.ollila@iki.fi>,\r
+       Michael Stapelberg <michael+nm@stapelberg.de>, notmuch@notmuchmail.org\r
+Subject: Re: [BUG] Saving attachments containing UTF-8 chars\r
+In-Reply-To: <m2pq416xzl.fsf@guru.guru-group.fi>\r
+References: <x6sj8xiexi.fsf@midna.zekjur.net>\r
+       <m2pq416xzl.fsf@guru.guru-group.fi>\r
+User-Agent: Notmuch/0.14+45~g6ea9330 (http://notmuchmail.org) Emacs/24.1.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Sun, 18 Nov 2012 00:29:31 -0500\r
+Message-ID: <87zk2f1nt0.fsf@betacantrips.com>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 18 Nov 2012 05:29:37 -0000\r
+\r
+Tomi Ollila <tomi.ollila@iki.fi> writes:\r
+\r
+> I can verify this bug: I copied 'rawmail' to my mail store and attempted\r
+> to 'w' the attacment and got the same result (after notmuch new).\r
+>\r
+> The saving code first does\r
+> notmuch show --format=raw id:"508953E6.70006@gmail.com"\r
+> which decodes OK on command line, and to the buffer when \r
+> kill-buffer is outcommented in (with-current-notmuch-show-message ...) \r
+> macro.\r
+\r
+I was able to see this behavior, and Tomi did a good job tracking down\r
+where it was :)\r
+\r
+I even see the bytes as presented in the file. When moving point to the\r
+problematic character, and doing M-x describe-char, it says:\r
+\r
+          buffer code: #xE2 #x80 #x99\r
+            file code: #xE2 #x80 #x99 (encoded by coding system utf-8)\r
+\r
+buffer-file-coding-system is, of course, utf-8.\r
+\r
+Writing this buffer using C-x C-w encodes it correctly too. So I think\r
+this is an emacs MIME problem. We call mm-save-part, which calls\r
+mm-save-part-to-file, which calls mm-with-unibyte-buffer. Hmm..\r
+\r
+Indeed, it seems that inserting this character into a file that's been\r
+marked "unibyte" using (set-buffer-multibyte nil) turns it into the ^Y\r
+character (ASCII code 0x19 -- the character that comes out in the patch\r
+file). There's probably a technical reason that this should be true, but\r
+I can't think of why that would be.\r
+\r
+> I attempted a set of trial-&-error tricks to get the attachment\r
+> saved "correctly", and at least this seems to do the trick:\r
+>\r
+> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el\r
+> index f273eb4..a6a85c0 100644\r
+> --- a/emacs/notmuch-show.el\r
+> +++ b/emacs/notmuch-show.el\r
+> @@ -203,9 +203,11 @@ For example, if you wanted to remove an \"unread\" tag and add a\r
+>       (let ((id (notmuch-show-get-message-id)))\r
+>         (let ((buf (generate-new-buffer (concat "*notmuch-msg-" id "*"))))\r
+>           (with-current-buffer buf\r
+> -        (call-process notmuch-command nil t nil "show" "--format=raw" id)\r
+> -           ,@body)\r
+> -     (kill-buffer buf)))))\r
+> +       (let ((coding-system-for-read 'no-conversion)\r
+> +             (coding-system-for-write 'no-conversion))\r
+> +         (call-process notmuch-command nil t nil "show" "--format=raw" id)\r
+> +         ,@body))))))\r
+> +%%   (kill-buffer buf)))))\r
+[snip]\r
+> (kill-buffer is outcommented above for testing purposes)\r
+>\r
+> To test this this needs to me evaluated and then the functions\r
+> using this macro (notmuch-show-save-attachments  in this case)\r
+>\r
+> Smart suggestions for proper fix ?\r
+\r
+Well, we could limit it just to saving attachments (putting the let\r
+around the with-current-notmuch-show-message). That feels like it could\r
+be right, because intuitively saving an attachment should be done\r
+without any conversions. Or even the above doesn't seem so bad. My vague\r
+feeling is that messages should always be ASCII, or at least mm-* will\r
+interpret it that way, so decoding them into any other character set\r
+might cause problems. Anyone understand character sets?\r
+\r
+Ethan\r