--- /dev/null
+Return-Path: <aclements@csail.mit.edu>\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 B97CB431FC0\r
+ for <notmuch@notmuchmail.org>; Fri, 14 Dec 2012 21:17:04 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 Dx5UpesgqxJg for <notmuch@notmuchmail.org>;\r
+ Fri, 14 Dec 2012 21:17:02 -0800 (PST)\r
+Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU\r
+ [18.9.25.14])\r
+ by olra.theworths.org (Postfix) with ESMTP id 5ADD3429E2E\r
+ for <notmuch@notmuchmail.org>; Fri, 14 Dec 2012 21:16:53 -0800 (PST)\r
+X-AuditID: 1209190e-b7f516d0000008e4-9b-50cc07c49763\r
+Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])\r
+ by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP\r
+ id B8.8A.02276.4C70CC05; Sat, 15 Dec 2012 00:16:52 -0500 (EST)\r
+Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
+ by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id qBF5Gqt3021678; \r
+ Sat, 15 Dec 2012 00:16:52 -0500\r
+Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
+ (authenticated bits=0)\r
+ (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+ by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id qBF5Gplj011585\r
+ (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);\r
+ Sat, 15 Dec 2012 00:16:52 -0500 (EST)\r
+Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80)\r
+ (envelope-from <aclements@csail.mit.edu>)\r
+ id 1Tjk7G-0006zU-PF; Sat, 15 Dec 2012 00:16:50 -0500\r
+Date: Sat, 15 Dec 2012 00:16:50 -0500\r
+From: Austin Clements <aclements@csail.mit.edu>\r
+To: Mark Walters <markwalters1009@gmail.com>\r
+Subject: Re: [PATCH 2/3] emacs: show: add overlays for each part\r
+Message-ID: <20121215051650.GE6187@mit.edu>\r
+References: <1354663662-20524-1-git-send-email-markwalters1009@gmail.com>\r
+ <1354663662-20524-3-git-send-email-markwalters1009@gmail.com>\r
+ <87txrtnssb.fsf@awakening.csail.mit.edu>\r
+ <87obhy72o1.fsf@qmul.ac.uk>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+In-Reply-To: <87obhy72o1.fsf@qmul.ac.uk>\r
+User-Agent: Mutt/1.5.21 (2010-09-15)\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1j3CfibAYPldG4vVc3ksrt+cyezA\r
+ 5LFz1l12j2erbjEHMEVx2aSk5mSWpRbp2yVwZey8soOlYKtSRffXXYwNjPOluxg5OSQETCTm\r
+ rF/MCmGLSVy4t56ti5GLQ0hgH6PE8q0LWCGcDYwS0xr+QDkXmSRm3VvIDuGsZpRYdm8nWD+L\r
+ gKrE7WWT2EBsNgF9iRVrJ4HFRQR0JG4fWsAOYjMLSEt8+93MBGILCzhIzJ+2ECzOK6AtceNY\r
+ IwvE0EuMEv1n57BAJAQlTs58wgLRrCVx499LoGYOsEHL/3GAmJwCGhKdb1JAKkQFVCSmnNzG\r
+ NoFRaBaS5llImmchNC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6yXm1mil5pSuokRHNaS\r
+ fDsYvx5UOsQowMGoxMO7I+J0gBBrYllxZe4hRkkOJiVR3lsMZwKE+JLyUyozEosz4otKc1KL\r
+ DzFKcDArifCKbQEq501JrKxKLcqHSUlzsCiJ815JuekvJJCeWJKanZpakFoEk5Xh4FCS4P3B\r
+ BjRUsCg1PbUiLTOnBCHNxMEJMpwHaPh+kBre4oLE3OLMdIj8KUZFKXHeqyAJAZBERmkeXC8s\r
+ 7bxiFAd6RZg3GqSKB5iy4LpfAQ1mAhocd+k4yOCSRISUVAOjK4sV09OWV2XSa2uP73m6wdhe\r
+ Odsz5lDNUtcsdbadNnc2cccvqVzE+MPkwwfu320bFx/xLC7Keq489erMd3d2Ffe8EHN/evtm\r
+ 54pVazYF/PprF7D9x6VXr/auNHO/cs3//9sPN/v0Tz/Yrvb8RJurrVdxrvtlPTH3XY5b7Nwk\r
+ Et+4B76afZNxlRJLcUaioRZzUXEiAOeiYrwWAwAA\r
+X-Mailman-Approved-At: Fri, 14 Dec 2012 23:21:25 -0800\r
+Cc: notmuch@notmuchmail.org\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: Sat, 15 Dec 2012 05:17:05 -0000\r
+\r
+Quoth Mark Walters on Dec 13 at 8:54 am:\r
+> >> + (string= chosen-type inner-type))))))\r
+> >\r
+> > You could let-bind the (not (or ..)) to some variable ("hide" perhaps)\r
+> > in the let above to avoid this crazy line length.\r
+> >\r
+> >> inner-parts)\r
+> >> \r
+> >> (when notmuch-show-indent-multipart\r
+> >> @@ -840,17 +839,52 @@ message at DEPTH in the current thread."\r
+> >> (setq handlers (cdr handlers))))\r
+> >> t)\r
+> >> \r
+> >> -(defun notmuch-show-insert-bodypart (msg part depth)\r
+> >> - "Insert the body part PART at depth DEPTH in the current thread."\r
+> >> +(defun notmuch-show-insert-part-overlays (msg beg end not-shown)\r
+> >\r
+> > s/not-shown/hide/? Or hidden?\r
+> >\r
+> >> + "Add an overlay to the part between BEG and END"\r
+> >> + (let* ((button (button-at beg))\r
+> >> + (part-beg (and button (1+ (button-end button)))))\r
+> >> +\r
+> >> + ;; If the part contains no text we do not make it toggleable.\r
+> >> + (unless (or (not button) (eq part-beg end))\r
+> >\r
+> > (when (and button (/= part-beg end)) ...) ?\r
+> >\r
+> >> + (let ((base-label (button-get button :base-label))\r
+> >> + (overlay (make-overlay part-beg end))\r
+> >> + (message-invis-spec (plist-get msg :message-invis-spec))\r
+> >> + (invis-spec (make-symbol "notmuch-part-region")))\r
+> >> +\r
+> >> + (overlay-put overlay 'invisible (list invis-spec message-invis-spec))\r
+> >\r
+> > Non-trivial buffer invisibility specs are really bad for performance\r
+> > (Emacs' renderer does the obvious O(n^2) thing when rendering a buffer\r
+> > with an invisibility spec). Unfortunately, because of notmuch-wash and\r
+> > the way overlays with trivial 'invisible properties combine with\r
+> > overlays with list-type 'invisible properties combine, I don't think it\r
+> > can be avoided. But if we get rid of buffer invisibility specs from\r
+> > notmuch-wash, this code can also get much simpler.\r
+> \r
+> How do you plan to get rid of the invisibility properties from notmuch\r
+> wash? \r
+\r
+Not the invisibility properties. The invisibility specs. The\r
+performance impact and difficult composition comes from using buffer\r
+invisibility specs, but the 'invisible text property can be simply nil\r
+or t. These are just as easy to manipulate as the generated\r
+invisibility symbols we use all over the place (you just manipulate\r
+the property directly instead of the buffer invisibility spec). They\r
+also compose like you'd want (if any overlay over some text has\r
+'invisible set to t, then that text is invisible).\r
+\r
+> >> + (overlay-put overlay 'isearch-open-invisible #'notmuch-wash-region-isearch-show)\r
+> >\r
+> > This will leave the "(not shown)" in the part header if isearch unfolds\r
+> > the part.\r
+> >\r
+> > Do we even want isearch to unfold parts? It's not clear we do for\r
+> > multipart/alternative. If we do, probably the right thing is something\r
+> > like\r
+> \r
+> I don't think we want to search hidden bodyparts so I just deleted this\r
+> line.\r
+> \r
+> >\r
+> > (overlay-put overlay 'notmuch-show-part-button button)\r
+> > (overlay-put overlay 'isearch-open-invisible #'notmuch-show-part-isearch-open)\r
+> >\r
+> > (defun notmuch-show-part-isearch-open (overlay)\r
+> > (notmuch-show-toggle-invisible-part-action\r
+> > (overlay-get overlay 'notmuch-show-part-button)))\r
+> >\r
+> >> + (overlay-put overlay 'priority 10)\r
+> >> + (overlay-put overlay 'type "part")\r
+> >> + ;; Now we have to add invis-spec to every overlay this\r
+> >> + ;; overlay contains, otherwise these inner overlays will\r
+> >> + ;; override this one.\r
+> >\r
+> > Interesting. In the simple case of using nil or t for 'invisible, the\r
+> > specs do combine as one would expect, but you're right that, with a\r
+> > non-trivial invisibility-spec, the highest priority overlay wins. It's\r
+> > too bad we don't know the depth of the part or we could just set the\r
+> > overlay priority. This is another thing that would go away if we didn't\r
+> > use buffer invisibility-specs.\r
+> \r
+> I don't think priorities get it right. As far as I could tell if you\r
+> have two overlays at different priorities both with invisibility\r
+> properties then the higher priority overlay decides visibility by\r
+> itself: that is if it says invisible then the text is invisible, and if\r
+> it says visible then the text is visible.\r
+\r
+Yes. I think I was confused when I claimed we could use priorities,\r
+since I can't reconstruct how I thought we could do that.\r
projects / notmuch-archives.git / commitdiff