bug#18545: 24.4.50: Bug - forward-line inside with-selected-window

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: lompik@voila.fr,  18545@debbugs.gnu.org
> Date: Fri, 26 Sep 2014 10:13:45 -0400
> 
> >> Why does
> >> (with-selected-window (get-buffer-window "*Completions*")
> >> (recenter 5))
> >> require an explicit call to wset_redisplay from recenter, whereas
> >> (with-selected-window (get-buffer-window "*Completions*")
> >> (forward-line 1))
> >> doesn't need an explicit call to wset_redisplay (or bset_redisplay) from
> >> forward-line?
> > I think that's because forward-line moves point, while recenter
> > doesn't.
> 
> But I don't see why moving point would help: calling wset_redisplay
> should only change the fact that this window is considered for
> redisplay

There are redisplay optimizations that don't depend on whether we
consider a window for redisplay; see around line 13700 in xdisp.c from
emacs-24.  You will see a little ways below that place that we test
point against its recorded value in w->last_point, for example.

> so if it's needed for the recenter case, that means that
> without it, the window would not be considered at all

'with-selected-window makes' the offending window selected, and the
selected window is always considered for redisplay, right?

> which in turn should imply that in the forward-line case we wouldn't
> notice that point has changed, unless set_point_both ends up calling
> bset_redisplay somehow (but I fail to see how).

If you really want me to come up with a detailed explanation of why
the forward-line case doesn't need wset_redisplay, I can do that, but
it will require some digging.

My fixes where based on turning on trace-redisplay and observing
thereafter that, in the forward-line case the offending window was
shown in the trace, but always with an indication that the forced
window-start was OK, whereas in the recenter case the offending window
was not shown at all in the trace.