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

[Anders Lindgren <andlind@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3621 bytes --]

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 <wildgruber@tu-berlin.de>
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

[-- Attachment #2: Type: text/html, Size: 4915 bytes --]