From: Austin Clements Date: Sat, 24 Jan 2015 21:16:59 +0000 (-0500) Subject: emacs: Return unibyte strings for binary part data X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=9d19f325f5a0879e2f646e83e59595d5cb345de3;p=notmuch.git 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: "). --- 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)))))