Re: [O] Enriched/Org is a colorful Org

[Eli Zaretskii]

> From: Carsten Dominik <address@hidden>
> Date: Fri, 12 Apr 2013 00:49:32 +0200
> Cc: "address@hidden List" <address@hidden>
> 
> > 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.