unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: David Edmondson <dme@dme.org>
To: notmuch@notmuchmail.org
Subject: [PATCH v1 3/3] emacs: Improve the acquisition of text parts.
Date: Tue,  8 Mar 2016 17:12:59 +0000	[thread overview]
Message-ID: <1457457179-4707-4-git-send-email-dme@dme.org> (raw)
In-Reply-To: <1457457179-4707-1-git-send-email-dme@dme.org>

`notmuch-get-bodypart-text' assumed that it is always possible to
acquire text/* parts via the sexp output format. This is not true if the
part in question has a content type of application/octet-stream but is
being interpreted as text/* based on the extension of the part filename.

Rework `notmuch-get-bodypart-text' to use the raw output format to
address this and make the implementation common with that of
`notmuch-get-bodypart-binary'.
---
 emacs/notmuch-lib.el | 73 ++++++++++++++++++++++------------------------------
 1 file changed, 31 insertions(+), 42 deletions(-)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 89c01a5..75a3706 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -537,6 +537,34 @@ the given type."
    (lambda (part) (notmuch-match-content-type (plist-get part :content-type) type))
    parts))
 
+(defun notmuch--get-bodypart-raw (msg part process-crypto binaryp cache)
+  (let* ((plist-elem (if binaryp :content-binary :content))
+	 (data (or (plist-get part plist-elem)
+		   (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.
+		     (when binaryp
+		       (set-buffer-multibyte nil))
+		     (let ((args `("show" "--format=raw"
+				   ,(format "--part=%s" (plist-get part :id))
+				   ,@(when process-crypto '("--decrypt"))
+				   ,(notmuch-id-to-query (plist-get msg :id))))
+			   (coding-system-for-read
+			    (if binaryp 'no-conversion 'utf-8)))
+		       (apply #'call-process notmuch-command nil '(t nil) nil args)
+		       (buffer-string))))))
+    (when (and cache data)
+      (plist-put part plist-elem data))
+    data))
+
 (defun notmuch-get-bodypart-binary (msg part process-crypto &optional cache)
   "Return the unprocessed content of PART in MSG as a unibyte string.
 
@@ -547,57 +575,18 @@ this does no charset conversion.
 
 If CACHE is non-nil, the content of this part will be saved in
 MSG (if it isn't already)."
-  (let ((data (plist-get part :binary-content)))
-    (when (not data)
-      (let ((args `("show" "--format=raw"
-		    ,(format "--part=%d" (plist-get part :id))
-		    ,@(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)
-	    (setq data (buffer-string)))))
-      (when cache
-	;; Cheat.  part is non-nil, and `plist-put' always modifies
-	;; the list in place if it's non-nil.
-	(plist-put part :binary-content data)))
-    data))
+  (notmuch--get-bodypart-raw msg part process-crypto t cache))
 
 (defun notmuch-get-bodypart-text (msg part process-crypto &optional cache)
   "Return the text content of PART in MSG.
 
 This returns the content of the given part as a multibyte Lisp
 string after performing content transfer decoding and any
-necessary charset decoding.  It is an error to use this for
-non-text/* parts.
+necessary charset decoding.
 
 If CACHE is non-nil, the content of this part will be saved in
 MSG (if it isn't already)."
-  (let ((content (plist-get part :content)))
-    (when (not content)
-      ;; Use show --format=sexp to fetch decoded content
-      (let* ((args `("show" "--format=sexp" "--include-html"
-		     ,(format "--part=%s" (plist-get part :id))
-		     ,@(when process-crypto '("--decrypt"))
-		     ,(notmuch-id-to-query (plist-get msg :id))))
-	     (npart (apply #'notmuch-call-notmuch-sexp args)))
-	(setq content (plist-get npart :content))
-	(when (not content)
-	  (error "Internal error: No :content from %S" args)))
-      (when cache
-	(plist-put part :content content)))
-    content))
+  (notmuch--get-bodypart-raw msg part process-crypto nil cache))
 
 ;; Workaround: The call to `mm-display-part' below triggers a bug in
 ;; Emacs 24 if it attempts to use the shr renderer to display an HTML
-- 
2.1.4

  parent reply	other threads:[~2016-03-08 17:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-08 17:12 [PATCH v1 0/3] Improve the acquisition of text parts David Edmondson
2016-03-08 17:12 ` [PATCH v1 1/3] emacs: `notmuch-show-insert-part-multipart/encrypted' should not assume the presence of a button David Edmondson
2016-03-08 17:12 ` [PATCH v1 2/3] emacs: Neaten `notmuch-show-insert-bodypart-internal' David Edmondson
2016-03-08 17:12 ` David Edmondson [this message]
2016-03-13 15:22 ` [PATCH v1 0/3] Improve the acquisition of text parts Mark Walters
2016-03-14  8:31   ` David Edmondson
2016-03-14 11:49     ` David Bremner
2016-03-26  9:18       ` Mark Walters
2016-03-27 20:48 ` David Bremner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1457457179-4707-4-git-send-email-dme@dme.org \
    --to=dme@dme.org \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).