From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii Subject: Re: Enriched/Org is a colorful Org Date: Fri, 12 Apr 2013 09:41:07 +0300 Message-ID: <83ip3s9rp8.fsf@gnu.org> 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> Reply-To: Eli Zaretskii Return-path: Received: from eggs.gnu.org ([208.118.235.92]:32858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQXfa-0002c2-AO for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 02:41:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQXfZ-0006Wd-DG for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 02:41:10 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:50538) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQXfZ-0006Sz-4R for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 02:41:09 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0ML400E00QJ72Y00@a-mtaout20.012.net.il> for emacs-orgmode@gnu.org; Fri, 12 Apr 2013 09:41:07 +0300 (IDT) In-reply-to: <8461B483-8CC4-4D37-94BD-5CBEED773ADE@gmail.com> 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: Carsten Dominik Cc: emacs-orgmode@gnu.org > From: Carsten Dominik > Date: Fri, 12 Apr 2013 00:49:32 +0200 > Cc: "emacs-orgmode@gnu.org List" > > > 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. > > 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. Just search xdisp.c for "overlay", you will see the story quite clearly, I think. 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. 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.