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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: rudalics <at> gmx.at
Cc: lompik <at> voila.fr, 18545 <at> debbugs.gnu.org
Subject: bug#18545: 24.4.50: Bug - forward-line inside with-selected-window
Date: Sat, 27 Sep 2014 22:55:38 +0300

> Date: Sat, 27 Sep 2014 22:38:08 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: lompik <at> voila.fr, 18545 <at> debbugs.gnu.org
> 
> > Date: Sat, 27 Sep 2014 21:03:30 +0200
> > From: martin rudalics <rudalics <at> gmx.at>
> > CC: lompik <at> voila.fr, 18545 <at> 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.

Previous Next

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