--- /dev/null
+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