--- /dev/null
+Return-Path: <m.walters@qmul.ac.uk>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 6045E429E25\r
+ for <notmuch@notmuchmail.org>; Thu, 5 Sep 2013 11:46:54 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -1.098\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
+ tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
+ NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id yLCz72ibkO3T for <notmuch@notmuchmail.org>;\r
+ Thu, 5 Sep 2013 11:46:48 -0700 (PDT)\r
+Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 44AD0431FDB\r
+ for <notmuch@notmuchmail.org>; Thu, 5 Sep 2013 11:46:48 -0700 (PDT)\r
+Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
+ by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1VHeZj-0005Ug-6w; Thu, 05 Sep 2013 19:46:44 +0100\r
+Received: from 93-97-24-31.zone5.bethere.co.uk ([93.97.24.31] helo=localhost)\r
+ by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1VHeZi-0001F0-UG; Thu, 05 Sep 2013 19:46:39 +0100\r
+From: Mark Walters <markwalters1009@gmail.com>\r
+To: Austin Clements <amdragon@MIT.EDU>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH v2] emacs: show: lazy part bugfix\r
+In-Reply-To: <20130904161628.GC1426@mit.edu>\r
+References: <1377246875-7784-1-git-send-email-markwalters1009@gmail.com>\r
+ <1378279835-28288-1-git-send-email-markwalters1009@gmail.com>\r
+ <20130904145639.GB1426@mit.edu>\r
+ <87hae07fhs.fsf@servo.finestructure.net>\r
+ <20130904161628.GC1426@mit.edu>\r
+User-Agent: Notmuch/0.15.2+269~g01f5508 (http://notmuchmail.org) Emacs/23.4.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Thu, 05 Sep 2013 19:46:37 +0100\r
+Message-ID: <87txhz14z6.fsf@qmul.ac.uk>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: quoted-printable\r
+X-Sender-Host-Address: 93.97.24.31\r
+X-QM-SPAM-Info: Sender has good ham record. :)\r
+X-QM-Body-MD5: 4e01612d53a146601ef488817f3523d1 (of first 20000 bytes)\r
+X-SpamAssassin-Score: 0.0\r
+X-SpamAssassin-SpamBar: /\r
+X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
+ determine if it is\r
+ spam. We require at least 5.0 points to mark a message as spam.\r
+ This message scored 0.0 points. Summary of the scoring: \r
+ * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
+ provider * (markwalters1009[at]gmail.com)\r
+ * 0.0 AWL AWL: From: address is in the auto white-list\r
+X-QM-Scan-Virus: ClamAV says the message is clean\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://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: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 05 Sep 2013 18:46:54 -0000\r
+\r
+\r
+Thanks to Austin's prodding and debugging and pointing out contradictory\r
+evidence I have looked into this bug in more detail and think I have got\r
+the actual cause this time.\r
+\r
+Having chased it all down I think there is a one line fix. Since I had\r
+already written the rest of the email when I discovered this I include\r
+the diagnosis below but most people will probably want to skip to the\r
+patch at the end.\r
+\r
+---\r
+\r
+The problem only occurs for message of this sort of form\r
+ =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative 896783 bytes\r
+ =E2=94=9C=E2=94=80=E2=95=B4text/plain 379 bytes\r
+ =E2=94=94=E2=94=AC=E2=95=B4multipart/related 892556 bytes\r
+ =E2=94=9C=E2=94=80=E2=95=B4text/html 1236 bytes\r
+ =E2=94=94=E2=94=80=E2=95=B4image/jpeg inline [photo.JPG] 890841 bytes\r
+\r
+The important features are that initially the multipart/related is\r
+hidden, and that when the multipart/related part is shown the child\r
+image/jpeg is hidden (that is what happens in Istvan's patch and could\r
+also happen with the inner part also being multipart/alternative but\r
+not, I think, if the inner part were multipart/mixed).\r
+\r
+Now the code for hiding parts starts with the normal button and then\r
+toggles the button (this is to make sure the button gets the correct\r
+label text). When doing so this code looks at the first character of the\r
+button, stores the text-properties, replaces the button with the toggled\r
+button, puts the text-properties back. Since insert does not put in text\r
+properties we do need this save restore.\r
+\r
+In the normal case where a hidden part is inserted it is on a newline\r
+where the current text-properties are nil. Thus the save/restore of text\r
+properties does nothing in this case; after this is done the correct\r
+text-properties are applied to the whole part (with the proviso that\r
+:notmuch-part does not over-ride subpart's :notmuch-part property)\r
+\r
+In the problem case above we have a line with=20\r
+\r
+[multipart/related (hidden)]\r
+\r
+The whole of this line including the \n has the multipart-related\r
+:notmuch-part\r
+\r
+Now when we do the lazy insertion we toggle this button (which behaves\r
+correctly), go to the end of the button insert a \n and then insert the\r
+child parts.\r
+\r
+At this point we have\r
+\r
+[multipart/related]\n\r
+\n\r
+\r
+the [multipart/related] has the multipart/related :notmuch-part info the\r
+first \n does not (as we just inserted) and the second \n does because\r
+it is the original \n\r
+\r
+Now if we insert a part button for a hidden part we insert the button\r
+and toggle it. Finally we get the problem: this toggle saves and\r
+restores (to the whole button) the text-properties from *point* which is\r
+the \n so includes the multipart/related\r
+:notmuch-part text-property\r
+\r
+If we save and restore from the start of the button we solve all of the\r
+problems (I think)\r
+\r
+Best wishes=20\r
+\r
+Mark\r
+\r
+\r
+---\r
+ emacs/notmuch-show.el | 2 +-\r
+ 1 files changed, 1 insertions(+), 1 deletions(-)\r
+\r
+diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el\r
+index 20844f0..0267574 100644\r
+--- a/emacs/notmuch-show.el\r
++++ b/emacs/notmuch-show.el\r
+@@ -503,7 +503,7 @@ message at DEPTH in the current thread."\r
+ (new-start (button-start button))\r
+ (button-label (button-get button :base-label))\r
+ (old-point (point))\r
+- (properties (text-properties-at (point)))\r
++ (properties (text-properties-at (button-start button)))\r
+ (inhibit-read-only t))\r
+ ;; Toggle the button itself.\r
+ (button-put button :notmuch-part-hidden (not show))\r
+--=20\r
+1.7.9.1\r
+\r