GNU bug report logs - #29325
26.0.90: Info scrolling stuck

Previous Next

Package: emacs;

Reported by: charles <at> aurox.ch (Charles A. Roelli)

Date: Thu, 16 Nov 2017 19:41:01 UTC

Severity: normal

Found in version 26.0.90

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch
Cc: 29325 <at> debbugs.gnu.org
Subject: bug#29325: 26.0.90: Info scrolling stuck
Date: Wed, 22 Nov 2017 17:38:26 +0200
> Date: Tue, 21 Nov 2017 21:42:59 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 29325 <at> debbugs.gnu.org
> 
> > When causing the problematic behavior, redisplay_window reaches
> > try_to_scroll via this if statement:
> > 
> >        if (!cursor_row_fully_visible_p (w, false, false))
> > 	{
> > 	  /* Point does appear, but on a line partly visible at end of window.
> > 	     Move it back to a fully-visible line.  */
> > 	  new_vpos = window_box_height (w);
> > 	  /* But if window_box_height suggests a Y coordinate that is
> > 	     not less than we already have, that line will clearly not
> > 	     be fully visible, so give up and scroll the display.
> > 	     This can happen when the default face uses a font whose
> > 	     dimensions are different from the frame's default
> > 	     font.  */
> > 	  if (new_vpos >= w->cursor.y)
> > 	    {
> > 	      w->cursor.vpos = -1;
> > 	      clear_glyph_matrix (w->desired_matrix);
> > 	      goto try_to_scroll;
> > 	    }
> > 	}
> > 
> > That is, (!cursor_row_fully_visible_p (w, false, false)) and
> > (new_vpos >= w->cursor.y) evaluate to true.
> 
> And what are the values of new_vpos and w->cursor.y in this case?  And
> what is w->cursor.vpos?
> 
> > try_to_scroll looks like this:
> 
> I suspect we shouldn't go there in this case.

Actually, I think this code is not supposed to run in the case you
describe, i.e. when the user invokes a scrolling command.  So I think
the root cause is elsewhere.  Does the patch below fix the problem?

diff --git a/src/window.c b/src/window.c
index 7f47252..504dcd3 100644
--- a/src/window.c
+++ b/src/window.c
@@ -5355,6 +5355,9 @@ window_scroll_pixel_based (Lisp_Object window, int n, bool whole, bool noerror)
       /* We moved the window start towards BEGV, so PT may be now
 	 in the scroll margin at the bottom.  */
       move_it_to (&it, PT, -1,
+		  /* We subtract WINDOW_HEADER_LINE_HEIGHT because
+		     it.y is relative to the bottom of the header
+		     line, see above.  */
 		  (it.last_visible_y - WINDOW_HEADER_LINE_HEIGHT (w)
                    - partial_line_height (&it) - this_scroll_margin - 1),
 		  -1,
@@ -5392,11 +5395,14 @@ window_scroll_pixel_based (Lisp_Object window, int n, bool whole, bool noerror)
 
       /* See if point is on a partially visible line at the end.  */
       if (it.what == IT_EOB)
-	partial_p = it.current_y + it.ascent + it.descent > it.last_visible_y;
+	partial_p =
+	  it.current_y + it.ascent + it.descent
+	  > it.last_visible_y - WINDOW_HEADER_LINE_HEIGHT (w);
       else
 	{
 	  move_it_by_lines (&it, 1);
-	  partial_p = it.current_y > it.last_visible_y;
+	  partial_p =
+	    it.current_y > it.last_visible_y - WINDOW_HEADER_LINE_HEIGHT (w);
 	}
 
       if (charpos == PT && !partial_p
@@ -5415,7 +5421,7 @@ window_scroll_pixel_based (Lisp_Object window, int n, bool whole, bool noerror)
 	    goal_y = this_scroll_margin;
 	  SET_TEXT_POS_FROM_MARKER (start, w->start);
 	  start_display (&it, w, start);
-	  /* It would be wrong to subtract CURRENT_HEADER_LINE_HEIGHT
+	  /* It would be wrong to subtract WINDOW_HEADER_LINE_HEIGHT
 	     here because we called start_display again and did not
 	     alter it.current_y this time.  */
 	  move_it_to (&it, -1, window_scroll_pixel_based_preserve_x,




This bug report was last modified 7 years and 182 days ago.

Previous Next


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