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
next prev parent 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
List information: https://www.orgmode.org/
* 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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).