bug#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window

[Anders Lindgren]

> Basically, it is supposed to do whatever Follow mode does today

That is not specific enough, especially if you take into consideration
that I have only a vague idea about what Follow mode does.  Moreover,
I'm not sure we should ask the display engine do everything it does.
For example, selecting the next/previous window when point moves off
the limits of the current window seems to be something that is easy to
do in Lisp.

So please do try to come up with a list of requirements that should be
moved to the display engine.  I guess setting the window start point
when scrolling would be one; what else?

You're absolutely correct. Most of Follow mode functions could be kept in elisp. In fact, most of them are trivial, take scrolling for example, it simple moves the current window down a suitable amount, and let the post-command hook take care of the rest.

As a starting point, I would say that it's main responsibility is to keep the windows aligned, so that one window start where the previous left of. The second thing it should do is that it should "auto select" other windows when, for example, the cursor moved down below the end of the window.

In short, do what the post-command-hook does.

I will try to give you a deeper description as soon as I can find some time to do it.

 

> > I would suggest that we also post feature requests for things that would
> > > help the situation on a shorter time scale. Primarily, I would like to be
> > > able, on a window-by-window basis, control whether or not a window should
> > > be recentered, when empty.
> >
> > What should Emacs do instead of recentering a window?
> >
>
> It should keep the window empty.

Shouldn't be hard to implement, given some buffer-local variable.

Great. I would suggest that it should be implemented so that the actual test could be written in elisp. In the Follow mode case, the test should be that the buffer is in Follow mode and that it's not the first window. However, I could think of other modes -- one example being Two-column mode, another Scroll all mode -- where this could be useful, but with other criterias.

In the simplest form it could be a symbol, nil for "no", t for "yes", and for all other cases call the function it is bound to. Of course, one could make it into a hook, so that more than one mode could have a say, but I think that might be overengineering it a bit...

    -- Anders