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

[martin rudalics]

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

That's likely me.  Under certain conditions I do `recenter' with a
negative argument in `post-command-hook' which basically looks like

             (recenter (max 0 (- (window-height) 7)))

which triggers w->force_start being set here in xdisp.c:

      if (IT_CHARPOS (it) == PT)
        w->force_start = 1;

So my case _is_ very likely special.  Still "bringing point back into
view" shouldn't make point appear on a partially visible line.  Or am I
missing something?

martin