bug#16431: 24.3.50; `follow-adjust-windows' sometimes fails (patch included)

[Stefan Monnier]

> You can close it for now and if I see the problem again, I will let you know.

Done, thanks.

> One thing still seems to be problematic -- `follow-adjust-window' only work
> properly when `win' is *selected*.

Indeed, I was tempted to add a (cl-assert (eq win (selected-window))) or
to remove the `win' argument altogether.  I didn't do it mostly because
I remembered that we're in feature freeze.

> In other words, that I would like to see is the following:

>         (let ((source-pos ....))
>           (with-current-buffer (window-buffer win)
>             (goto-char source-pos)
>             (follow-adjust-window win)))

I don't understand why you'd want to compute source-pos while outside of
(window-buffer win).

> When windows are aligned, Follow mode does not set the window start or do
> anything else to disturb the redisplay.

In my suggested approach, when windows are aligned, after each call to
redisplay-window, window-end is cheap (since it was just computed and is
hence marked as up-to-date) and since the windows are already properly
aligned you'd find that window-start does not need to be updated, which
in turn would ensure that the next redisplay-window is also cheap.

> In this scenario it would definitively help if there were a "window-only
> redisplay" or, even better, a "silent redisplay" that would calculate where
> the window would end up, but not actually draw anything. (Here, I must
> admit that my knowledge of the display engine is limited.)

My intention would be for redisplay-window to only update the matrices
(i.e. the internal representation of the rendered window) and let the
subsequent full redisplay deal with updating the display.  My
knowledge of the display engine is also limited, but I think such
a redisplay-window function should not be too hard to write.


        Stefan