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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 15 Jan 2014 23:39:50 -0500
> Cc: 16431@debbugs.gnu.org
> 
> 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.

Not sure if this discussion belongs here, but...

I don't have a clear understanding of how your suggestion would work.
As you well know, a redisplay cycle has 2 parts: first, the "desired"
glyph matrices are created for each window that needs to be
redisplayed, and then the differences between the "desired" and the
"current" glyph matrices are computed and delivered to the glass.  The
second part is inside the call to update_frame.

Now, the above doesn't say, but your later message indicates that by
"redisplay a window" you mean only the first part.  However, the
current redisplay cycle marks a window's display "accurate" only after
update_frame was called and was able to complete its job.  I'm not
sure we can mark a window "up to date" without actually delivering the
stiff to the glass.

Next, there's a complication on TTYs: there, update_frame updates the
entire frame at once, not one window at a time (as it does on GUI
displays).  So the TTY redisplay cannot easily update several windows
one by one without doing a lot of redundant work.

The function that redisplays a window in your sense already exists:
it's redisplay_window; you just need to expose it to Lisp.  But
calling that function from pre-redisplay-function, i.e. from inside
redisplay, means you are potentially re-entering the display engine,
which is non-reentrant.

OTOH, the job at hand is very simple: we need to ask the display
engine to redisplay several windows in a particular order, and to
determine the window-start of each of these windows from the
window-end of the previous one.  This is a much easier job, one that
doesn't require re-entering the display engine, nor usurping its job
by redisplaying some windows behind its back "by hand".

IOW, I'm not sure it is a good idea to use pre-redisplay-function for
doing part of redisplay's job.  Instead, we should let the display
engine do its job, and provide some hints to it that would produce the
necessary effect.