all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: Enriched/Org is a colorful Org
Date: Fri, 12 Apr 2013 00:46:02 +0200	[thread overview]
Message-ID: <8CA8128C-26D2-49E4-81BF-E68D4EAE83E5@gmail.com> (raw)
In-Reply-To: <83wqs99dv0.fsf@gnu.org>


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

  reply	other threads:[~2013-04-11 22:46 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-10  4:02 Enriched/Org is a colorful Org Jambunathan K
2013-04-10  9:54 ` Suvayu Ali
2013-04-10 10:16   ` Carsten Dominik
2013-04-10 10:39     ` Torsten Wagner
2013-04-10 10:48     ` Suvayu Ali
2013-04-10 10:53       ` Carsten Dominik
2013-04-10 11:20         ` Sebastien Vauban
2013-04-10 11:26           ` Carsten Dominik
2013-04-10 12:15           ` Jambunathan K
2013-04-10 11:57     ` Jambunathan K
2013-04-10 16:21     ` Eli Zaretskii
2013-04-10 16:43       ` Jambunathan K
2013-04-10 17:13         ` Eli Zaretskii
2013-04-10 19:58       ` Carsten Dominik
2013-04-10 20:16         ` Sebastien Vauban
2013-04-11  2:58           ` Carsten Dominik
2013-04-11 17:30             ` Eli Zaretskii
2013-04-11 22:49               ` Carsten Dominik
2013-04-12  6:41                 ` Eli Zaretskii
2013-04-12  7:13                   ` Carsten Dominik
2013-04-12  8:31                     ` Eli Zaretskii
2013-04-12 10:56                       ` Carsten Dominik
2013-04-12 11:49                         ` Torsten Wagner
2013-04-12 13:03                           ` Eli Zaretskii
2013-04-12 18:00                             ` Suvayu Ali
2013-04-12 18:38                               ` Eli Zaretskii
2013-04-13 10:50                                 ` Suvayu Ali
2013-04-12 12:36                         ` Eli Zaretskii
2013-04-13 12:24                           ` Sean O'Halpin
2013-04-13 14:38                             ` Jambunathan K
2013-04-13 15:01                             ` Eli Zaretskii
2013-04-12  8:35                     ` Bastien
2013-04-12 14:45                       ` François Pinard
2013-04-18 20:37                         ` Samuel Wales
2013-04-11 17:27         ` Eli Zaretskii
2013-04-11 22:46           ` Carsten Dominik [this message]
2013-04-10 12:12   ` Jambunathan K

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8CA8128C-26D2-49E4-81BF-E68D4EAE83E5@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.