emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Enriched/Org is a colorful Org
Date: Fri, 12 Apr 2013 09:41:07 +0300	[thread overview]
Message-ID: <83ip3s9rp8.fsf@gnu.org> (raw)
In-Reply-To: <8461B483-8CC4-4D37-94BD-5CBEED773ADE@gmail.com>

> From: Carsten Dominik <carsten.dominik@gmail.com>
> Date: Fri, 12 Apr 2013 00:49:32 +0200
> Cc: "emacs-orgmode@gnu.org List" <emacs-orgmode@gnu.org>
> 
> > 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.

  reply	other threads:[~2013-04-12  6:41 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 [this message]
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
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=83ip3s9rp8.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=carsten.dominik@gmail.com \
    --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).