From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Enriched/Org is a colorful Org Date: Fri, 12 Apr 2013 09:13:47 +0200 Message-ID: <5A8E6625-33C1-4B94-A78E-B08268C57A5F@gmail.com> References: <87a9p79gnv.fsf@gmail.com> <20130410095450.GA31506@kuru.dyndns-at-home.com> <83a9p69x0c.fsf@gnu.org> <262C4E11-6D4B-4033-A619-1702CC8D0F94@gmail.com> <86fvyycfa9.fsf@somewhere.org> <83vc7t9dr1.fsf@gnu.org> <8461B483-8CC4-4D37-94BD-5CBEED773ADE@gmail.com> <83ip3s9rp8.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:39686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQYBD-0002pm-3k for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 03:13:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQYBC-00006b-52 for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 03:13:51 -0400 In-Reply-To: <83ip3s9rp8.fsf@gnu.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eli Zaretskii Cc: emacs-orgmode@gnu.org On 12 apr. 2013, at 08:41, Eli Zaretskii wrote: >> From: Carsten Dominik >> Date: Fri, 12 Apr 2013 00:49:32 +0200 >> Cc: "emacs-orgmode@gnu.org List" >>=20 >>> Overlays should be OK as long as they aren't too many, and as long = as >>> you don't move them around too much, particularly in = post-command-hook >>> or some such. >>=20 >> This explanation sounds to me as if the display engine is building >> some kind of tree of overlays to find properties changes quickly. = Too bad I don't have time to understand this stuff in more detail, it = sounds interesting. >=20 > Just search xdisp.c for "overlay", you will see the story quite > clearly, I think. My Sunday pleasure reading project. >=20 > There are actually 2 aspects that make display engine's job harder > with overlays. One is indeed that finding overlays that "cover" a > given buffer position is not a very efficient operation. The display > engine tries to overcome this to some extent by "centering" the > overlay data base around the place in the buffer it is rendering. > This is done for every screen line that is being examined by the > display code. >=20 > The other problem is that there's no easy way of finding out which > parts of the buffer are being affected by changes in overlays. The > consequence of this is that redisplay cannot easily determine whether > a given portion of what's on the glass needs to be redrawn when > overlays change. The analysis of which part(s) of a window need to be > redrawn is at the heart of redisplay optimizations, whereby Emacs > tries very hard to reuse the portions of display that are already up > to date. Changes in overlays defeat that. Therefore, changing _any_ > overlays in a buffer disables most, if not all, redisplay > optimizations, meaning that the entire portion of the buffer that is > displayed will be completely redrawn each time overlays _anywhere_ in > the buffer are changed. Wow. OK. I need to think to that, and I will try to take a fresh look at overlay use in Org. So the reason that the combination with hi-line is slow is because hl-line is using post-command-hook to move its overlay, and redisplay of a full window with org-mode is slow because so much stuff is hidden and Emacs makes a full re-evaluation of what needs to be displayed? This makes sense. Thanks for taking the time to get me this far. - Carsten=