On 12 apr. 2013, at 10:31, Eli Zaretskii <e...@gnu.org> wrote: >> From: Carsten Dominik <carsten.domi...@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.
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