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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: andlind@gmail.com,  16431@debbugs.gnu.org
> Date: Thu, 16 Jan 2014 13:58:41 -0500
> 
> > 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".

Sure, that's what I said above: update_frame is where the display is
being updated.  In a GUI session, it calls update_window_tree, which
updates the windows one by one, whereas in the TTY case it updates the
entire foreground frame.  In both cases, preparation of the desired
matrices is separate from updating the display.

> It's not quite that simple because point may want to move from one
> window to the other instead of scrolling.

Not sure this part should be in C, as it just selects a window.  But
if so, it's not hard.

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

Right.  The hard part, as always, is to come up with a design that is
flexible enough to serve these use cases, and yet simple enough to
avoid placing more burden on redisplay.