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

[Anders Lindgren <andlind@gmail.com>]

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

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

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