follow-mode: extremely slow in combination with org-mode

[Anders Lindgren]

Hi!

I decided to go to the bottom of this, and had to do some digging, which took a little bit longer than I thought it would do, sorry about the delay.

On Wed, Jun 27, 2018 at 6:43 PM, Gerald Wildgruber <address@hidden> wrote:

> - Follow-mode is has problems when the width of the windows differ,
> especially if you have long lines that spill over from one window to
> another. I've written a support package to set up side-by-side windows in a
> pixel-perfect way, https://github.com/Lindydancer/multicolumn -- please try
> if and see if follow-mode runs more smoothly.

Actually I use this already! [...]

You just made my day!

Can you tell if the function that uses so much of cpu time --
follow-calc-win-end -- in the form it is now part of new emacs versions,
has any evident problem compared to your own longer version in pre
version 22 emacs? Cf Alan's posting in this thread:
https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00522.html

The main difference is that the current version handles clipped lines at the end of a window. My original version predates the addition of the UPDATE optional parameter to window-end. Effectively, it calculated window-end plus one. Anyway, it would not work in a modern Emacs where fonts of different heights could be used.

The modern version handles clipped lines by repeating a clipped screen line in the next window. This is for two reasons:

1) Lines where only one or a few pixels are displayed would effectively be hidden from users, if they weren't repeated in the next window.

2) When the cursor is placed on a clipped line, Emacs recenters the window, which breaks Follow mode. Instead, Follow mode selects the next window, which is displaying the same line. (Or rather, this is the way it was supposed to work, I just noticed that it is broken in Emacs 26.1 -- the original window is scrolled anyway. I don't know how long it as been broken.)

Lines in this context are screen lines, not physical lines. In other words, if you have a long wrapped physical line, the function should return a suitable position inside the line where the next window should start.

The follow-calc-win-end function should return window-end plus one if the line isn't clipped, and the beginning of the bottommost screen line if it is clipped. (The patch supplied by Eli doesn't do this, so it won't work -- but I guess its main purpose of the patch was to figure out which parts of the function consume processing power.)

So, where do we go from here? First, I noticed that pos-visible-in-window-p can take an argument PARTIALLY that, when non-nil, makes the function provide information about whether or not the position is partially visible. Presumably, it could replace the pixel juggling the current function do. However, if the big time thief is `window-end` with an non-nil UPDATE argument we must either make is faster (at least after self-insert-command) or figure out a way to avoid calling it too often, somehow.

Being (somewhat) older and ((hopefully) somewhat) wiser, I wish I had written a test suite for Follow mode, or at least a test protocol. However, Follow mode was written 12 years before work on Ert even had started... Anyway, having a test suite containing all the corner cases would make it easier to try out alternative implementations, and it would prevent us from introducing bugs like the one I just found.

I wished I had more time to work on this, but it took me a week just to find the time to write this mail, so clearly I'm not the best candidate at the moment.

Sincerely,

    Anders Lindgren