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

[Carsten Dominik]

On 12 apr. 2013, at 10:31, Eli Zaretskii <address@hidden> wrote:

>> 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.

I guess outline mode does have the exact same problem in this case, in
fact any mode with large amount of hidden text.

> 
> Also, recall that, under line-move-visual, which is nowadays on by
> default,

Not in my setup, but since it the default, yes, this causes more
issues.  Another important point to be aware of.


> 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.

Thanks again.

- Carsten