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

[Eli Zaretskii]

[Please CC me on responses, as I'm not subscribed to this list.]

> From: Carsten Dominik <address@hidden>
> Date: Wed, 10 Apr 2013 21:58:06 +0200
> Cc: address@hidden
> 
> > I beg the Org developers to please be very careful when introducing
> > expensive display features such as overlays into Org.  Org already
> > puts the Emacs display engine to its limits in many of its popular
> > features;
> 
> this is interesting input, I was not aware of this.  Has this been discussed 
> before, can you point me to relevant threads, and what are the symptoms of 
> the display engine being at its limits?

You won't find explicit discussions of this, except maybe a random
comment from me here and there.  There aren't too many discussions
about the display engine in general; maybe it's my fault.

But you can find indirect evidence to what I say in quite a few
reports about slow redisplay.  Here's one example (it's just the first
one that popped up on Google):

  http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00276.html

Note how two display features: bidi and hl-line -- each one of them
cause significant slow-down in Org buffers, and almost nowhere else.

This is just an example.  I keep bumping into similar issues
frequently enough to lead me to the conclusion you see above.

In general, hiding from display large parts of a buffer, and using a
lot of display strings and overlays that add to buffer text or replace
buffer text with something else -- these all make redisplay much more
expensive.  In particular, moving overlays disables many redisplay
optimizations, so e.g. any mode that moves overlays as result of
post-command-hook will considerably slow down display and degrade user
experience.

After hacking the display code for a few years, it is painfully clear
to me that its basic design assumed that such use cases are rare.  Org
mode makes these assumptions more and more false, and it does that
faster than the CPU speed improves ;-)

For these reasons, and as long as we don't have any development going
on that aims at a complete redesign of the display engine, I think
every feature, especially one expected to be popular, that adversely
impacts redisplay efficiency, should be considered very carefully, and
the various alternatives for its implementation assessed also from
this aspect.

HTH