Re: Enriched/Org is a colorful Org

[Carsten Dominik <carsten.dominik@gmail.com>]

On 11.4.2013, at 19:27, Eli Zaretskii <eliz@gnu.org> wrote:

> [Please CC me on responses, as I'm not subscribed to this list.]
> 
>> From: Carsten Dominik <carsten.dominik@gmail.com>
>> Date: Wed, 10 Apr 2013 21:58:06 +0200
>> Cc: emacs-orgmode@gnu.org
>> 
>>> 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.

Yes, OK, I also remember reports like this.  Funny, often it is not Org by itself, but in combination with something else that affects the display engine.

> 
> 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.

OK, this is a concrete thing we can be on the lookout for.  I don't think we do that, but I will take a look.

> 
> 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.

This is clear enough.  I will try to keep this in mind and evaluate changes in Org in this way.  If you have other concrete things where you think Org could be improved in this direction, let us know.

> 
> HTH

Certainly, thank you.

- Carsten