--- /dev/null
+Return-Path: <dme@dme.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 11BFC6DE1403\r
+ for <notmuch@notmuchmail.org>; Tue, 8 Mar 2016 09:13:10 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.373\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.373 tagged_above=-999 required=5 tests=[AWL=0.440, \r
+ DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7,\r
+ RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NEUTRAL=0.652,\r
+ UNPARSEABLE_RELAY=0.001] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id 0jVazW2UDITF for <notmuch@notmuchmail.org>;\r
+ Tue, 8 Mar 2016 09:13:08 -0800 (PST)\r
+Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com\r
+ [74.125.82.67]) by arlo.cworth.org (Postfix) with ESMTPS id 8B77B6DE01FF for\r
+ <notmuch@notmuchmail.org>; Tue, 8 Mar 2016 09:13:07 -0800 (PST)\r
+Received: by mail-wm0-f67.google.com with SMTP id l68so5321441wml.3\r
+ for <notmuch@notmuchmail.org>; Tue, 08 Mar 2016 09:13:07 -0800 (PST)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=dme-org.20150623.gappssmtp.com; s=20150623;\r
+ h=from:to:subject:date:message-id:in-reply-to:references;\r
+ bh=BPxiJfT4/8TedppqeXT/kyUUP2eBHpNERC4OTtJICHA=;\r
+ b=uufg7cdcmVl5cTFsLqS+wntF8Pc5YKikkCCd5MUAYCiqETTi/7aXwRmaasvCFYAfTu\r
+ jHlu67vmTz0r/KFvhspDrmN+CLwkKIjfsVz2HL1NoSw7ddxuDWYWy1zxC4mZIrDJ5EPo\r
+ 19jZ1y+wSRNwSly2dvaBzPI2MVfBejDxGKQZM65iyI7cTdpSHS8fDnhxXMiJfHGgCgpU\r
+ frUtNXaOAqIZJUlmLMH96fiGKNB+aycsyiNESCu0yuDzQdqdo2li1cpyEDl5fez+Ewr4\r
+ t3Y2g+JEyv6kFoibwSBDl0YVMuIMgllw4WYC9OUvCjye6z+7Vdivm9/4omF7B7V28Vsx\r
+ zirg==\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=1e100.net; s=20130820;\r
+ h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to\r
+ :references;\r
+ bh=BPxiJfT4/8TedppqeXT/kyUUP2eBHpNERC4OTtJICHA=;\r
+ b=EBApaRUnQQE/+qMmmyZHe8xrpS6AL0bH/2M5hITxJVjNv4XKzvUeJmDUtexyi3fUfI\r
+ xCX4co4Lm6Za5zc+ralRFU6IPJyNoEHD37n6SZfGCjtdOHeLPDDJ4ltF9woL1vsyj7Vy\r
+ 4YFbe/ee+lFyAb7hjjW/FpLFPus/FZ3QgI20QFMRv2lQ+/bIJwu5aEcA04aDxFd+UxEW\r
+ vvVgSEMHUNGWuHolQqLmj0f2/P3SueNxKOwIa6PMFnFBNaEtS8jYG4e6zybf0uUlbG4T\r
+ L8iCMyrDSLshq30miPVRECvmOg2wEY38b5a3iog6eQyK7ANFMbJsxAig5gMfHwIFmhxK\r
+ hccA==\r
+X-Gm-Message-State:\r
+ AD7BkJL+lHB4IhEjV9HQ4GfeEER7KJffw4GKHREti3yUEykzwHX0W8UhFg69bnEKUWCaLA==\r
+X-Received: by 10.28.9.71 with SMTP id 68mr20248218wmj.33.1457457186291;\r
+ Tue, 08 Mar 2016 09:13:06 -0800 (PST)\r
+Received: from disaster-area.hh.sledj.net (disaster-area.hh.sledj.net.\r
+ [81.149.164.25])\r
+ by smtp.gmail.com with ESMTPSA id l135sm4369544wmb.13.2016.03.08.09.13.05\r
+ for <notmuch@notmuchmail.org>\r
+ (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\r
+ Tue, 08 Mar 2016 09:13:05 -0800 (PST)\r
+Received: from localhost (disaster-area.hh.sledj.net [local])\r
+ by disaster-area.hh.sledj.net (OpenSMTPD) with ESMTPA id 89ea9002\r
+ for <notmuch@notmuchmail.org>; Tue, 8 Mar 2016 17:12:59 +0000 (UTC)\r
+From: David Edmondson <dme@dme.org>\r
+To: notmuch@notmuchmail.org\r
+Subject: [PATCH v1 3/3] emacs: Improve the acquisition of text parts.\r
+Date: Tue, 8 Mar 2016 17:12:59 +0000\r
+Message-Id: <1457457179-4707-4-git-send-email-dme@dme.org>\r
+X-Mailer: git-send-email 2.1.4\r
+In-Reply-To: <1457457179-4707-1-git-send-email-dme@dme.org>\r
+References: <1457457179-4707-1-git-send-email-dme@dme.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://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: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 08 Mar 2016 17:13:10 -0000\r
+\r
+`notmuch-get-bodypart-text' assumed that it is always possible to\r
+acquire text/* parts via the sexp output format. This is not true if the\r
+part in question has a content type of application/octet-stream but is\r
+being interpreted as text/* based on the extension of the part filename.\r
+\r
+Rework `notmuch-get-bodypart-text' to use the raw output format to\r
+address this and make the implementation common with that of\r
+`notmuch-get-bodypart-binary'.\r
+---\r
+ emacs/notmuch-lib.el | 73 ++++++++++++++++++++++------------------------------\r
+ 1 file changed, 31 insertions(+), 42 deletions(-)\r
+\r
+diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el\r
+index 89c01a5..75a3706 100644\r
+--- a/emacs/notmuch-lib.el\r
++++ b/emacs/notmuch-lib.el\r
+@@ -537,6 +537,34 @@ the given type."\r
+ (lambda (part) (notmuch-match-content-type (plist-get part :content-type) type))\r
+ parts))\r
+ \r
++(defun notmuch--get-bodypart-raw (msg part process-crypto binaryp cache)\r
++ (let* ((plist-elem (if binaryp :content-binary :content))\r
++ (data (or (plist-get part plist-elem)\r
++ (with-temp-buffer\r
++ ;; Emacs internally uses a UTF-8-like multibyte string\r
++ ;; representation by default (regardless of the coding\r
++ ;; system, which only affects how it goes from outside data\r
++ ;; to this internal representation). This *almost* never\r
++ ;; matters. Annoyingly, it does matter if we use this data\r
++ ;; in an image descriptor, since Emacs will use its internal\r
++ ;; data buffer directly and this multibyte representation\r
++ ;; corrupts binary image formats. Since the caller is\r
++ ;; asking for binary data, a unibyte string is a more\r
++ ;; appropriate representation anyway.\r
++ (when binaryp\r
++ (set-buffer-multibyte nil))\r
++ (let ((args `("show" "--format=raw"\r
++ ,(format "--part=%s" (plist-get part :id))\r
++ ,@(when process-crypto '("--decrypt"))\r
++ ,(notmuch-id-to-query (plist-get msg :id))))\r
++ (coding-system-for-read\r
++ (if binaryp 'no-conversion 'utf-8)))\r
++ (apply #'call-process notmuch-command nil '(t nil) nil args)\r
++ (buffer-string))))))\r
++ (when (and cache data)\r
++ (plist-put part plist-elem data))\r
++ data))\r
++\r
+ (defun notmuch-get-bodypart-binary (msg part process-crypto &optional cache)\r
+ "Return the unprocessed content of PART in MSG as a unibyte string.\r
+ \r
+@@ -547,57 +575,18 @@ this does no charset conversion.\r
+ \r
+ If CACHE is non-nil, the content of this part will be saved in\r
+ MSG (if it isn't already)."\r
+- (let ((data (plist-get part :binary-content)))\r
+- (when (not data)\r
+- (let ((args `("show" "--format=raw"\r
+- ,(format "--part=%d" (plist-get part :id))\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\r
+- ;; system, which only affects how it goes from outside data\r
+- ;; to this internal representation). This *almost* never\r
+- ;; matters. Annoyingly, it does matter if we use this data\r
+- ;; in an image descriptor, since Emacs will use its internal\r
+- ;; data buffer directly and this multibyte representation\r
+- ;; corrupts binary image formats. Since the caller is\r
+- ;; asking for binary data, a unibyte string is a more\r
+- ;; 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
+- (setq data (buffer-string)))))\r
+- (when cache\r
+- ;; Cheat. part is non-nil, and `plist-put' always modifies\r
+- ;; the list in place if it's non-nil.\r
+- (plist-put part :binary-content data)))\r
+- data))\r
++ (notmuch--get-bodypart-raw msg part process-crypto t cache))\r
+ \r
+ (defun notmuch-get-bodypart-text (msg part process-crypto &optional cache)\r
+ "Return the text content of PART in MSG.\r
+ \r
+ This returns the content of the given part as a multibyte Lisp\r
+ string after performing content transfer decoding and any\r
+-necessary charset decoding. It is an error to use this for\r
+-non-text/* parts.\r
++necessary charset decoding.\r
+ \r
+ If CACHE is non-nil, the content of this part will be saved in\r
+ MSG (if it isn't already)."\r
+- (let ((content (plist-get part :content)))\r
+- (when (not content)\r
+- ;; Use show --format=sexp to fetch decoded content\r
+- (let* ((args `("show" "--format=sexp" "--include-html"\r
+- ,(format "--part=%s" (plist-get part :id))\r
+- ,@(when process-crypto '("--decrypt"))\r
+- ,(notmuch-id-to-query (plist-get msg :id))))\r
+- (npart (apply #'notmuch-call-notmuch-sexp args)))\r
+- (setq content (plist-get npart :content))\r
+- (when (not content)\r
+- (error "Internal error: No :content from %S" args)))\r
+- (when cache\r
+- (plist-put part :content content)))\r
+- content))\r
++ (notmuch--get-bodypart-raw msg part process-crypto nil cache))\r
+ \r
+ ;; Workaround: The call to `mm-display-part' below triggers a bug in\r
+ ;; Emacs 24 if it attempts to use the shr renderer to display an HTML\r
+-- \r
+2.1.4\r
+\r
projects / notmuch-archives.git / commitdiff