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

From: martin rudalics <[email-masked]>
Date: Sun, 28 Sep 2014 11:34:44 +0200

> 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