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 11:31:58 +0300	[thread overview]
Message-ID: <83fvyw9mkh.fsf@gnu.org> (raw)
In-Reply-To: <5A8E6625-33C1-4B94-A78E-B08268C57A5F@gmail.com>

> From: Carsten Dominik <carsten.dominik@gmail.com>
> Date: Fri, 12 Apr 2013 09:13:47 +0200
> Cc: emacs-orgmode@gnu.org
> 
> > Just search xdisp.c for "overlay", you will see the story quite
> > clearly, I think.
> 
> My Sunday pleasure reading project.

Good luck, and let me know if you need something explained.  The
commentary at the beginning of the file might serve as an
introduction, although it doesn't really touch the issue at hand.

> So the reason that the combination with hi-line is slow is because
> hl-line is using post-command-hook to move its overlay, and redisplay
> of a full window with org-mode is slow because so much stuff is
> hidden and Emacs makes a full re-evaluation of what needs
> to be displayed?

Right.  If hi-line (or any similar mode) is off, then at least
horizontal cursor motion should be fast, because then Emacs knows that
nothing changed, and finding the place where to put the cursor on the
same line it was before is relatively easy.

But even C-n and C-p is quite another story in an Org buffer: Emacs
needs to determine where that puts point, and doing so generally means
traversing all of the hidden parts of the buffer between the line
which was current and the new current line.  In a complex Org buffer,
that could easily be many thousands of buffer positions.

Also, recall that, under line-move-visual, which is nowadays on by
default, Emacs moves by _screen_ lines, not by physical lines.  So a
simple C-n must internally emulate display to find the next line
visible on the screen by traversing the buffer one character at a time
and taking note of each and every text property and overlay in
between, until it finds the buffer position whose screen coordinates
are [X,Y+N], where [X,Y] are the coordinates of the previous cursor
position and N is the line height in pixels.  And this is just to find
where point will be; then the screen must actually be redisplayed,
which might mean more work, if the new position of point requires
scrolling, e.g. if cursor went off the scroll margins or whatever.

We only get reasonably fast performance with all this complexity
because our machines are incredibly fast.  But we are many times on
the edge, as the bug I cited and similar ones show.

  reply	other threads:[~2013-04-12  8:32 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 [this message]
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=83fvyw9mkh.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).