[PATCH v2 4/8] emacs: Return unibyte strings for binary part data
authorAustin Clements <amdragon@mit.edu>
Sat, 24 Jan 2015 21:16:59 +0000 (16:16 +1900)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 21:47:48 +0000 (14:47 -0700)
5a/5ce3675f0d4c99a3f571ba6538b0f3fb43aec2 [new file with mode: 0644]

diff --git a/5a/5ce3675f0d4c99a3f571ba6538b0f3fb43aec2 b/5a/5ce3675f0d4c99a3f571ba6538b0f3fb43aec2
new file mode 100644 (file)
index 0000000..8433702
--- /dev/null
@@ -0,0 +1,121 @@
+Return-Path: <amdragon@mit.edu>\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 77376429E2E\r
+       for <notmuch@notmuchmail.org>; Sat, 24 Jan 2015 13:18:05 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.138\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.138 tagged_above=-999 required=5\r
+       tests=[DNS_FROM_AHBL_RHSBL=2.438, RCVD_IN_DNSWL_MED=-2.3]\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 Bm4vOk2R+Z5F for <notmuch@notmuchmail.org>;\r
+       Sat, 24 Jan 2015 13:18:02 -0800 (PST)\r
+Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu\r
+       [18.7.68.36])\r
+       (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 4AB3D431FAF\r
+       for <notmuch@notmuchmail.org>; Sat, 24 Jan 2015 13:17:23 -0800 (PST)\r
+X-AuditID: 12074424-f791c6d000000d25-56-54c40be0dcc1\r
+Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
+       (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+       (Client did not present a certificate)\r
+       by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP\r
+       id 33.7A.03365.0EB04C45; Sat, 24 Jan 2015 16:17:20 -0500 (EST)\r
+Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
+       by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t0OLH9HW000699; \r
+       Sat, 24 Jan 2015 16:17:09 -0500\r
+Received: from drake (216-15-114-40.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com\r
+       [216.15.114.40]) (authenticated bits=0)\r
+       (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+       by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t0OLH6hx007455\r
+       (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);\r
+       Sat, 24 Jan 2015 16:17:07 -0500\r
+Received: from amthrax by drake with local (Exim 4.84)\r
+       (envelope-from <amdragon@mit.edu>)\r
+       id 1YF84n-0005Rb-LR; Sat, 24 Jan 2015 16:17:05 -0500\r
+From: Austin Clements <amdragon@mit.edu>\r
+To: notmuch@notmuchmail.org\r
+Subject: [PATCH v2 4/8] emacs: Return unibyte strings for binary part data\r
+Date: Sat, 24 Jan 2015 16:16:59 -0500\r
+Message-Id: <1422134223-20739-5-git-send-email-amdragon@mit.edu>\r
+X-Mailer: git-send-email 2.1.3\r
+In-Reply-To: <1422134223-20739-1-git-send-email-amdragon@mit.edu>\r
+References: <1422134223-20739-1-git-send-email-amdragon@mit.edu>\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFrrJIsWRmVeSWpSXmKPExsUixG6novuA+0iIwZnrZhY3WrsZLfbd2cJk\r
+       sXouj8X1mzOZLd6snMfqwOqx6/lfJo+ds+6yexz+upDF49mqW8weWw69Zw5gjeKySUnNySxL\r
+       LdK3S+DK2Nmwgr3gD3/Fj3urWRsYH/N0MXJySAiYSKy7eJQRwhaTuHBvPVsXIxeHkMBiJolF\r
+       jeuZIJyNjBL9b2ayg1QJCVxkkuj5oQ2RmMQoMXnKBzaQBJuAhsTvW4uZQGwRAWmJnXdns4LY\r
+       zAJ1En/nnAdbISzgJXH512wWEJtFQFViwtLVYDavgIPE+hUgCziAzpCT2LrOGyTMKeAocWPD\r
+       LhaIvQ4S3Z8b2SYw8i9gZFjFKJuSW6Wbm5iZU5yarFucnJiXl1qka66Xm1mil5pSuokRHIIu\r
+       KjsYmw8pHWIU4GBU4uH98e9QiBBrYllxZe4hRkkOJiVR3lW/DocI8SXlp1RmJBZnxBeV5qQW\r
+       H2KU4GBWEuG9sAEox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwcsI\r
+       jDUhwaLU9NSKtMycEoQ0EwcnyHAeoOEnuYBqeIsLEnOLM9Mh8qcYFaXEedeDJARAEhmleXC9\r
+       sBTxilEc6BVh3n0gVTzA9ALX/QpoMBPQ4ILtB0AGlyQipKQaGEt+mX158SrE/b+vjEAV89r4\r
+       XJ26/xvab2wLUdhfJL4vr/vE//21kzbMMOVoiu4wkFsrI+pya79swYynho1p5+WYUnT+f57a\r
+       YZ37/nzsNHf1CNk1LjIufSvV3A8c5Zm7qnzn74aPyzkfPDRMajp7T/TDJHfDQ69c9tlp8K97\r
+       dNL63YFnhl/uWSqxFGckGmoxFxUnAgDboNmd7AIAAA==\r
+Cc: tomi.ollila@iki.fi\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: Sat, 24 Jan 2015 21:18:05 -0000\r
+\r
+Unibyte strings are meant for representing binary data.  In practice,\r
+using unibyte versus multibyte strings affects *almost* nothing.  It\r
+does happen to matter if we use the binary data in an image descriptor\r
+(which is, helpfully, not documented anywhere and getting it wrong\r
+results in opaque errors like "Not a PNG image: <giant binary spew\r
+that is, in fact, a PNG image>").\r
+---\r
+ emacs/notmuch-lib.el | 12 +++++++++++-\r
+ 1 file changed, 11 insertions(+), 1 deletion(-)\r
+\r
+diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el\r
+index a0a95d8..3154725 100644\r
+--- a/emacs/notmuch-lib.el\r
++++ b/emacs/notmuch-lib.el\r
+@@ -530,7 +530,7 @@ (defun notmuch-parts-filter-by-type (parts type)\r
+    parts))\r
\r
+ (defun notmuch-get-bodypart-binary (msg part process-crypto)\r
+-  "Return the unprocessed content of PART in MSG.\r
++  "Return the unprocessed content of PART in MSG as a unibyte string.\r
\r
+ This returns the \"raw\" content of the given part after content\r
+ transfer decoding, but with no further processing (see the\r
+@@ -541,6 +541,16 @@ (defun notmuch-get-bodypart-binary (msg part process-crypto)\r
+               ,@(when process-crypto '("--decrypt"))\r
+               ,(notmuch-id-to-query (plist-get msg :id)))))\r
+     (with-temp-buffer\r
++      ;; Emacs internally uses a UTF-8-like multibyte string\r
++      ;; representation by default (regardless of the coding system,\r
++      ;; which only affects how it goes from outside data to this\r
++      ;; internal representation).  This *almost* never matters.\r
++      ;; Annoyingly, it does matter if we use this data in an image\r
++      ;; descriptor, since Emacs will use its internal data buffer\r
++      ;; directly and this multibyte representation corrupts binary\r
++      ;; image formats.  Since the caller is asking for binary data, a\r
++      ;; unibyte string is a more appropriate representation anyway.\r
++      (set-buffer-multibyte nil)\r
+       (let ((coding-system-for-read 'no-conversion))\r
+       (apply #'call-process notmuch-command nil '(t nil) nil args)\r
+       (buffer-string)))))\r
+-- \r
+2.1.3\r
+\r