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

Previous Next

Full log

Message #122 received at 18545 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lompik <at> voila.fr, 18545 <at> debbugs.gnu.org
Subject: Re: bug#18545: 24.4.50: Bug - forward-line inside with-selected-window
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.