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

[Stefan Monnier]

> (let ((owin (selected-window)))
>   (select-window (next-window))
>   (let ((follow-mode t))
>     (follow-adjust-window (selected-window) (/ (point-max) 2))
>   (select-window owin)))

This recipe doesn't work any more now that follow-adjust-window only
takes a single argument.

Do you have some other way to reproduce the original problem (or has it
been accidentally fixed by my recent commit)?

> 1226,1232c1226,1232

> <           (goto-char dest)

> <           (redisplay)

Your patch (just like the one in your other bug-report) has spurious
empty lines between every actual line.  Also I think it was reversed
(at least the "destination" code is the one that's been in Emacs for
a while now).  Finally, please use "diff -u" or "diff -c" format
for patches.

And since I'm here, thinking about how to better support follow-mode,
here's an idea: IIUC the main problem currently (other than the "empty
last buffers") is that we have to redisplay in order to find the
window-end, after which we can adjust subsequent windows, and force
another redisplay.  So we'd like redisplay of the various windows to be
done "in the right order" and be able to run some Elisp code in-between.
One option for that would be to provide a new `redisplay-window'
function which does a redisplay of only one window, and then use it
inside pre-redisplay-function.  This way, when we do a normal redisplay,
our follow-pre-redisplay-function would check if some of the windows use
follow-mode.  If so, follow-pre-redisplay-function would redisplay its
windows "manually" in the right order via `redisplay-window' (and setup
window-starts between each window, as appropriate).  After that the
normal redisplay would continue and would find those windows "already
up-to-date", which would avoid the double-redisplay.


        Stefan