[PATCH 07/11] 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 ece29c3..fc67b14 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -504,7 +504,7 @@ (defun notmuch-parts-filter-by-type (parts 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
@@ -515,6 +515,16 @@ (defun notmuch-get-bodypart-binary (msg part
process-crypto)
,@(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)
--
1.9.1
[PATCH 07/11] 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 ece29c3..fc67b14 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -504,7 +504,7 @@ (defun notmuch-parts-filter-by-type (parts 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
@@ -515,6 +515,16 @@ (defun notmuch-get-bodypart-binary (msg part
process-crypto)
,@(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)
--
1.9.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
