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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I don't have a clear understanding of how your suggestion would work.

Don't worry: you're not alone.

> Now, the above doesn't say, but your later message indicates that by
> "redisplay a window" you mean only the first part.

That's right.

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

Indeed, we may need to introduce a new boolean flag to distinguish the
"matrix up to date" from "display up to date".  I haven't had to deal
with this part of the code yet, so I'm not sure it will turn out.
But seen from a distance, it looks like it should be doable without
any serious restructuring.

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

That's actually good.  It means there's an existing road that goes in
the direction of separating the "update the matrix" vs "update the
display".

> The function that redisplays a window in your sense already exists:
> it's redisplay_window; you just need to expose it to Lisp.

More or less, yes.

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

Note that pre-redisplay-function is called from redisplay, not from
redisplay_window, so having pre-redisplay-function call redisplay_window
does not in itself create a circularity.
Of course, the devil is in the detail, but again, from a distance it
looks doable.

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

It's not quite that simple because point may want to move from one
window to the other instead of scrolling.  Of course, my plan currently
does not account for this either (my best guess so far is that we
should somehow tell redisplay-window not to change scroll and if
that causes point to move it means scrolling was needed, at which point
we can decide whether to move point to another window, or to call
redisplay-window again (but letting it scroll this time)).

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

Could be.  As you know, I'm a big fan of moving code to Elisp to provide
ever more rope for users to shoot themselves in the foot.

E.g. maybe the same functionality can later be used for scroll-all-mode
and two-columns-mode.  Presumably, ediff could also use that kind
of functionality.


        Stefan