Re: [O] Enriched/Org is a colorful Org

[Eli Zaretskii]

> From: Carsten Dominik <address@hidden>
> Date: Fri, 12 Apr 2013 09:13:47 +0200
> Cc: address@hidden
> 
> > 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.