From 9d19f325f5a0879e2f646e83e59595d5cb345de3 Mon Sep 17 00:00:00 2001 From: Austin Clements Date: Sat, 24 Jan 2015 16:16:59 -0500 Subject: [PATCH] emacs: Return unibyte strings for binary part data Unibyte strings are meant for representing binary data. In practice, using unibyte versus multibyte strings affects *almost* nothing. It does happen to matter if we use the binary data in an image descriptor (which is, helpfully, not documented anywhere and getting it wrong results in opaque errors like "Not a PNG image: "). --- emacs/notmuch-lib.el | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index a0a95d8f..31547253 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -530,7 +530,7 @@ the given type." parts)) (defun notmuch-get-bodypart-binary (msg part process-crypto) - "Return the unprocessed content of PART in MSG. + "Return the unprocessed content of PART in MSG as a unibyte string. This returns the \"raw\" content of the given part after content transfer decoding, but with no further processing (see the @@ -541,6 +541,16 @@ this does no charset conversion." ,@(when process-crypto '("--decrypt")) ,(notmuch-id-to-query (plist-get msg :id))))) (with-temp-buffer + ;; Emacs internally uses a UTF-8-like multibyte string + ;; representation by default (regardless of the coding system, + ;; which only affects how it goes from outside data to this + ;; internal representation). This *almost* never matters. + ;; Annoyingly, it does matter if we use this data in an image + ;; descriptor, since Emacs will use its internal data buffer + ;; directly and this multibyte representation corrupts binary + ;; image formats. Since the caller is asking for binary data, a + ;; unibyte string is a more appropriate representation anyway. + (set-buffer-multibyte nil) (let ((coding-system-for-read 'no-conversion)) (apply #'call-process notmuch-command nil '(t nil) nil args) (buffer-string))))) -- 2.39.2