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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 27 Sep 2014 22:38:08 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: lompik@voila.fr, 18545@debbugs.gnu.org
> 
> > Date: Sat, 27 Sep 2014 21:03:30 +0200
> > From: martin rudalics <rudalics@gmx.at>
> > CC: lompik@voila.fr, 18545@debbugs.gnu.org
> > 
> >  > You assume that the value of point displayed is consistent with the one
> >  > you see on the screen.  But maybe the value of point printed is the one
> >  > of the line *after* the last line.  So after printing that value,
> >  > redisplay re-sets point and at the end of the next command, the
> >  > displayed point will be the same as the last displayed one.
> > 
> > Indeed.  Redisplay moves point back exactly to where it was before.
> 
> Which is exactly what that code was written to do.

Hmm... I wonder why did we enter this area of the code, i.e. why did
this condition fire:

  /* Handle case where place to start displaying has been specified,
     unless the specified location is outside the accessible range.  */
  if (w->force_start || window_frozen_p (w))

Was w->force_start non-zero, or did window_frozen_p return non-zero?
If the former, can you see where was the force_start flag set?  (I'd
be surprised if it's the latter, since windows are only frozen when we
grow the minibuffer, which shouldn't be happening here, I think.)

In general, if the force_start flag of a window is set, that means we
shouldn't scroll, so bringing point back into view makes sense.