50/a9a43bd709e266e0b20c43113cb891e7ea6010

   1 Return-Path: <m.walters@qmul.ac.uk>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id C5257431FAF\r
   6         for <notmuch@notmuchmail.org>; Thu, 24 Apr 2014 03:46:50 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.502\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.502 tagged_above=-999 required=5\r
  12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
  13         NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id TC9hcCucmCBx for <notmuch@notmuchmail.org>;\r
  17         Thu, 24 Apr 2014 03:46:43 -0700 (PDT)\r
  18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id CDEEB431FAE\r
  22         for <notmuch@notmuchmail.org>; Thu, 24 Apr 2014 03:46:42 -0700 (PDT)\r
  23 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
  24         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
  25         (envelope-from <m.walters@qmul.ac.uk>)\r
  26         id 1WdHAm-0004oP-0w; Thu, 24 Apr 2014 11:46:36 +0100\r
  27 Received: from 5751dfa2.skybroadband.com ([87.81.223.162] helo=localhost)\r
  28         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)\r
  29         (envelope-from <m.walters@qmul.ac.uk>)\r
  30         id 1WdHAl-00085x-L2; Thu, 24 Apr 2014 11:46:31 +0100\r
  31 From: Mark Walters <markwalters1009@gmail.com>\r
  32 To: Austin Clements <amdragon@MIT.EDU>, notmuch@notmuchmail.org\r
  33 Subject: Re: [PATCH 08/11] emacs: Support caching in\r
  34         notmuch-get-bodypart-{binary, text}\r
  35 In-Reply-To: <1398105468-14317-9-git-send-email-amdragon@mit.edu>\r
  36 References: <1398105468-14317-1-git-send-email-amdragon@mit.edu>\r
  37         <1398105468-14317-9-git-send-email-amdragon@mit.edu>\r
  38 User-Agent: Notmuch/0.15.2+615~g78e3a93 (http://notmuchmail.org) Emacs/23.4.1\r
  39         (x86_64-pc-linux-gnu)\r
  40 Date: Thu, 24 Apr 2014 11:46:28 +0100\r
  41 Message-ID: <87sip3t37f.fsf@qmul.ac.uk>\r
  42 MIME-Version: 1.0\r
  43 Content-Type: text/plain; charset=us-ascii\r
  44 X-Sender-Host-Address: 87.81.223.162\r
  45 X-QM-Geographic: According to ripencc,\r
  46         this message was delivered by a machine in Britain (UK) (GB).\r
  47 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  48 X-QM-Body-MD5: 61734a60742b5b0478ef6dceac2f28de (of first 20000 bytes)\r
  49 X-SpamAssassin-Score: -0.1\r
  50 X-SpamAssassin-SpamBar: /\r
  51 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  52         determine if it is\r
  53         spam. We require at least 5.0 points to mark a message as spam.\r
  54         This message scored -0.1 points.\r
  55         Summary of the scoring: \r
  56         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  57         provider *      (markwalters1009[at]gmail.com)\r
  58         * -0.1 AWL AWL: From: address is in the auto white-list\r
  59 X-QM-Scan-Virus: ClamAV says the message is clean\r
  60 X-BeenThere: notmuch@notmuchmail.org\r
  61 X-Mailman-Version: 2.1.13\r
  62 Precedence: list\r
  63 List-Id: "Use and development of the notmuch mail system."\r
  64         <notmuch.notmuchmail.org>\r
  65 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  66         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  67 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  68 List-Post: <mailto:notmuch@notmuchmail.org>\r
  69 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  70 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  71         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  72 X-List-Received-Date: Thu, 24 Apr 2014 10:46:50 -0000\r
  73 \r
  74 \r
  75 On Mon, 21 Apr 2014, Austin Clements <amdragon@MIT.EDU> wrote:\r
  76 > (The actual code change here is small, but requires re-indenting\r
  77 > existing code.)\r
  78 > ---\r
  79 >  emacs/notmuch-lib.el | 52 ++++++++++++++++++++++++++++++----------------------\r
  80 >  1 file changed, 30 insertions(+), 22 deletions(-)\r
  81 >\r
  82 > diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el\r
  83 > index fc67b14..fee8512 100644\r
  84 > --- a/emacs/notmuch-lib.el\r
  85 > +++ b/emacs/notmuch-lib.el\r
  86 > @@ -503,33 +503,39 @@ (defun notmuch-parts-filter-by-type (parts type)\r
  87 >     (lambda (part) (notmuch-match-content-type (plist-get part :content-type) type))\r
  88 >     parts))\r
  89 >  \r
  90 > -(defun notmuch-get-bodypart-binary (msg part process-crypto)\r
  91 > +(defun notmuch-get-bodypart-binary (msg part process-crypto &optional cache)\r
  92 >    "Return the unprocessed content of PART in MSG as a unibyte string.\r
  93 >  \r
  94 >  This returns the \"raw\" content of the given part after content\r
  95 >  transfer decoding, but with no further processing (see the\r
  96 >  discussion of --format=raw in man notmuch-show).  In particular,\r
  97 >  this does no charset conversion."\r
  98 > -  (let ((args `("show" "--format=raw"\r
  99 > -             ,(format "--part=%d" (plist-get part :id))\r
 100 > -             ,@(when process-crypto '("--decrypt"))\r
 101 > -             ,(notmuch-id-to-query (plist-get msg :id)))))\r
 102 > -    (with-temp-buffer\r
 103 > -      ;; Emacs internally uses a UTF-8-like multibyte string\r
 104 > -      ;; representation by default (regardless of the coding system,\r
 105 > -      ;; which only affects how it goes from outside data to this\r
 106 > -      ;; internal representation).  This *almost* never matters.\r
 107 > -      ;; Annoyingly, it does matter if we use this data in an image\r
 108 > -      ;; descriptor, since Emacs will use its internal data buffer\r
 109 > -      ;; directly and this multibyte representation corrupts binary\r
 110 > -      ;; image formats.  Since the caller is asking for binary data, a\r
 111 > -      ;; unibyte string is a more appropriate representation anyway.\r
 112 > -      (set-buffer-multibyte nil)\r
 113 > -      (let ((coding-system-for-read 'no-conversion))\r
 114 > -     (apply #'call-process notmuch-command nil '(t nil) nil args)\r
 115 > -     (buffer-string)))))\r
 116 > -\r
 117 > -(defun notmuch-get-bodypart-text (msg part process-crypto)\r
 118 > +  (let ((data (plist-get part :binary-content)))\r
 119 > +    (when (not data)\r
 120 > +      (let ((args `("show" "--format=raw"\r
 121 > +                 ,(format "--part=%d" (plist-get part :id))\r
 122 > +                 ,@(when process-crypto '("--decrypt"))\r
 123 > +                 ,(notmuch-id-to-query (plist-get msg :id)))))\r
 124 > +     (with-temp-buffer\r
 125 > +       ;; Emacs internally uses a UTF-8-like multibyte string\r
 126 > +       ;; representation by default (regardless of the coding\r
 127 > +       ;; system, which only affects how it goes from outside data\r
 128 > +       ;; to this internal representation).  This *almost* never\r
 129 > +       ;; matters.  Annoyingly, it does matter if we use this data\r
 130 > +       ;; in an image descriptor, since Emacs will use its internal\r
 131 > +       ;; data buffer directly and this multibyte representation\r
 132 > +       ;; corrupts binary image formats.  Since the caller is\r
 133 > +       ;; asking for binary data, a unibyte string is a more\r
 134 > +       ;; appropriate representation anyway.\r
 135 > +       (set-buffer-multibyte nil)\r
 136 > +       (let ((coding-system-for-read 'no-conversion))\r
 137 > +         (apply #'call-process notmuch-command nil '(t nil) nil args)\r
 138 > +         (setq data (buffer-string)))))\r
 139 > +      (when cache\r
 140 > +     (plist-put part :binary-content data)))\r
 141 > +    data))\r
 142 \r
 143 I am a little puzzled by this but that could be lack of familiarity with\r
 144 elisp. As far as I can see plist-put will sometimes modify the original\r
 145 plist and sometimes return a new plist. If the latter happens then I\r
 146 think it works out as if we hadn't cached anything as the part passed to\r
 147 the function is unmodified. That might not matter in this case (though I\r
 148 find the lack of determinism disturbing).\r
 149 \r
 150 Or is something else going on?\r
 151 \r
 152 Best wishes\r
 153 \r
 154 Mark\r
 155 \r
 156 \r
 157 \r
 158 > +\r
 159 > +(defun notmuch-get-bodypart-text (msg part process-crypto &optional cache)\r
 160 >    "Return the text content of PART in MSG.\r
 161 >  \r
 162 >  This returns the content of the given part as a multibyte Lisp\r
 163 > @@ -546,7 +552,9 @@ (defun notmuch-get-bodypart-text (msg part process-crypto)\r
 164 >            (npart (apply #'notmuch-call-notmuch-sexp args)))\r
 165 >       (setq content (plist-get npart :content))\r
 166 >       (when (not content)\r
 167 > -       (error "Internal error: No :content from %S" args))))\r
 168 > +       (error "Internal error: No :content from %S" args)))\r
 169 > +      (when cache\r
 170 > +     (plist-put part :content content)))\r
 171 >      content))\r
 172 >  \r
 173 >  ;; Workaround: The call to `mm-display-part' below triggers a bug in\r
 174 > -- \r
 175 > 1.9.1\r
 176 >\r
 177 > _______________________________________________\r
 178 > notmuch mailing list\r
 179 > notmuch@notmuchmail.org\r
 180 > http://notmuchmail.org/mailman/listinfo/notmuch\r