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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29325 in the body.
You can then email your comments to 29325 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: charles <at> aurox.ch (Charles A. Roelli)
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.90: Info scrolling stuck
Date: Thu, 16 Nov 2017 20:41:09 +0100

I had the following issue under GNU/Linux, but not macOS:

1. C-h i
2. M-x buffer-face-mode RET (to enable a variable-width font)
3. m Info RET
4. g Help-Inv RET
5. Scroll to the bottom of the buffer with the mouse-wheel, then up again.

In step 5, I could scroll all the way to the bottom of the buffer (as
far as scrolling with the mouse wheel brings you), but scrolling back
to the top of the buffer would get stuck in the middle somewhere.
Even pressing DEL would not work.

The issue seems to happen only on some nodes.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch (Charles A. Roelli)
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Thu, 16 Nov 2017 21:47:59 +0200

> Date: Thu, 16 Nov 2017 20:41:09 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> 
> I had the following issue under GNU/Linux, but not macOS:
> 
> 1. C-h i
> 2. M-x buffer-face-mode RET (to enable a variable-width font)
> 3. m Info RET
> 4. g Help-Inv RET
> 5. Scroll to the bottom of the buffer with the mouse-wheel, then up again.
> 
> In step 5, I could scroll all the way to the bottom of the buffer (as
> far as scrolling with the mouse wheel brings you), but scrolling back
> to the top of the buffer would get stuck in the middle somewhere.
> Even pressing DEL would not work.

Not reproducible here.  Could be a macOS thing?  Or maybe it depends
on the font used as variable pitch (or its size)?

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

From: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Thu, 16 Nov 2017 21:45:35 +0100

> Date: Thu, 16 Nov 2017 21:47:59 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Thu, 16 Nov 2017 20:41:09 +0100
> > From: charles <at> aurox.ch (Charles A. Roelli)
> > 
> > I had the following issue under GNU/Linux, but not macOS:
> > 
> > 1. C-h i
> > 2. M-x buffer-face-mode RET (to enable a variable-width font)
> > 3. m Info RET
> > 4. g Help-Inv RET
> > 5. Scroll to the bottom of the buffer with the mouse-wheel, then up again.
> > 
> > In step 5, I could scroll all the way to the bottom of the buffer (as
> > far as scrolling with the mouse wheel brings you), but scrolling back
> > to the top of the buffer would get stuck in the middle somewhere.
> > Even pressing DEL would not work.
> 
> Not reproducible here.  Could be a macOS thing?  Or maybe it depends
> on the font used as variable pitch (or its size)?

Initially, it happened on Ubuntu GNU/Linux from emacs -q, not macOS.

However, I've just managed to trigger it on macOS from emacs -q, by
customizing face `variable-pitch' as follows:

Variable Pitch face: [sample]
    State : SET for current session only.
   The basic variable-pitch face.
   [X] Font Family: Sans Serif
   [ ] Font Foundry: --
   [ ] Width: --
   [X] Height: Value Menu Scale: 1.5

(The font family was already Sans Serif, I just changed the height
scale from 1.0 to 1.5).

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

From: Drew Adams <drew.adams <at> oracle.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>, 29325 <at> debbugs.gnu.org
Subject: RE: bug#29325: 26.0.90: Info scrolling stuck
Date: Thu, 16 Nov 2017 14:35:44 -0800 (PST)

> I had the following issue under GNU/Linux, but not macOS:

Does it happen with `emacs -Q` or only with your init file?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch (Charles A. Roelli)
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Fri, 17 Nov 2017 09:11:35 +0200

> Date: Thu, 16 Nov 2017 21:45:35 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> CC: 29325 <at> debbugs.gnu.org
> 
> > Not reproducible here.  Could be a macOS thing?  Or maybe it depends
> > on the font used as variable pitch (or its size)?
> 
> Initially, it happened on Ubuntu GNU/Linux from emacs -q, not macOS.

(I couldn't have known that, since your report lacked the details
collected by "M-x report-emacs-bug".)

> Variable Pitch face: [sample]
>     State : SET for current session only.
>    The basic variable-pitch face.
>    [X] Font Family: Sans Serif
>    [ ] Font Foundry: --
>    [ ] Width: --
>    [X] Height: Value Menu Scale: 1.5
> 
> (The font family was already Sans Serif, I just changed the height
> scale from 1.0 to 1.5).

Still not reproducible.

Does the same problem happen if you scroll with "M-1 M-v" instead of
the mouse wheel?  And what about M-<, does it get you to the beginning
of the node?

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

From: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Sun, 19 Nov 2017 17:49:50 +0100

> Date: Fri, 17 Nov 2017 09:11:35 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> CC: 29325 <at> debbugs.gnu.org
> Reply-to: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Variable Pitch face: [sample]
> >     State : SET for current session only.
> >    The basic variable-pitch face.
> >    [X] Font Family: Sans Serif
> >    [ ] Font Foundry: --
> >    [ ] Width: --
> >    [X] Height: Value Menu Scale: 1.5
> > 
> > (The font family was already Sans Serif, I just changed the height
> > scale from 1.0 to 1.5).
> 
> Still not reproducible.
> 
> Does the same problem happen if you scroll with "M-1 M-v" instead of
> the mouse wheel?

No: it works fine in that case.

> And what about M-<, does it get you to the beginning of the node?

Yes.

I looked into the definition of mwheel-scroll, and a comment by Stefan
in it seems to anticipate the behavior I see:

> 	  (cond ((eq button mouse-wheel-down-event)
>                  (condition-case nil (funcall mwheel-scroll-down-function amt)
>                    ;; Make sure we do indeed scroll to the beginning of
>                    ;; the buffer.
>                    (beginning-of-buffer
>                     (unwind-protect
>                         (funcall mwheel-scroll-down-function)
>                       ;; If the first scroll succeeded, then some scrolling
>                       ;; is possible: keep scrolling til the beginning but
>                       ;; do not signal an error.  For some reason, we have
>                       ;; to do it even if the first scroll signaled an
>                       ;; error, because otherwise the window is recentered
>                       ;; for a reason that escapes me.  This problem seems
>                       ;; to only affect scroll-down.  --Stef
>                       (set-window-start (selected-window) (point-min))))))

That is, when attempting to scroll down (as in, moving towards
beginning of buffer) under some mysterious circumstances, the window
gets recentered around point instead of being scrolled.  However, if
point is moved to the first line of the window, say, then the
scrolling does work as expected (as I've found out by experimenting
more with my initial recipe).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch (Charles A. Roelli)
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Sun, 19 Nov 2017 19:12:00 +0200

> Date: Sun, 19 Nov 2017 17:49:50 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> CC: 29325 <at> debbugs.gnu.org
> 
> > Still not reproducible.
> > 
> > Does the same problem happen if you scroll with "M-1 M-v" instead of
> > the mouse wheel?
> 
> No: it works fine in that case.

If this is only about scrolling with the mouse wheel, then perhaps the
factor which differs between our systems is the amount of scrolling
per wheel notch.  How many lines does a single notch scroll in your
case?  And does the problem happen if you turn the wheel slowly?

> > 	  (cond ((eq button mouse-wheel-down-event)
> >                  (condition-case nil (funcall mwheel-scroll-down-function amt)
> >                    ;; Make sure we do indeed scroll to the beginning of
> >                    ;; the buffer.
> >                    (beginning-of-buffer
> >                     (unwind-protect
> >                         (funcall mwheel-scroll-down-function)
> >                       ;; If the first scroll succeeded, then some scrolling
> >                       ;; is possible: keep scrolling til the beginning but
> >                       ;; do not signal an error.  For some reason, we have
> >                       ;; to do it even if the first scroll signaled an
> >                       ;; error, because otherwise the window is recentered
> >                       ;; for a reason that escapes me.  This problem seems
> >                       ;; to only affect scroll-down.  --Stef
> >                       (set-window-start (selected-window) (point-min))))))
> 
> That is, when attempting to scroll down (as in, moving towards
> beginning of buffer) under some mysterious circumstances, the window
> gets recentered around point instead of being scrolled.  However, if
> point is moved to the first line of the window, say, then the
> scrolling does work as expected (as I've found out by experimenting
> more with my initial recipe).

I have serious difficulties dealing with unexplained and undescribed
problems that happen "under mysterious circumstances".

If you build with --enable-checking='yes,glyphs', and then turn on
redisplay tracing with "M-x trace-redisplay" before scrolling with the
wheel, what do you see?  And how does that trace differ from when you
scroll with "M-1 M-v"?

(I find it useful to disable blink-cursor-mode and global-eldoc-mode
before such experiments, because they tend to trigger extra redisplay
cycles that conceal the interesting parts.)

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

From: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Mon, 20 Nov 2017 20:52:39 +0100

> Date: Sun, 19 Nov 2017 19:12:00 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > > Does the same problem happen if you scroll with "M-1 M-v" instead of
> > > the mouse wheel?
> > 
> > No: it works fine in that case.
> 
> If this is only about scrolling with the mouse wheel, then perhaps the
> factor which differs between our systems is the amount of scrolling
> per wheel notch.  How many lines does a single notch scroll in your
> case?  And does the problem happen if you turn the wheel slowly?

I don't have access to a GNU/Linux system at the moment, but if I
recall correctly, it would be 5 lines at a time, when scrolling
slowly.

The behavior is different depending on how fast the mouse wheel is
turned.  If it is turned slowly several times in a row, it is possible
to make window-start reach as far as the second or third line of the
buffer.  If you turn it once more, then window-start jerks down a few
lines instead of reaching the start of the buffer.  This can be
repeated ad infinitum.

In contrast, when turning the mouse wheel quickly (a few notches in
one second), it is not possible to get window-start anywhere near the
start of the buffer, except by using non-mouse commands or by setting
point closer to the top of the window first (with the mouse).

> > > 	  (cond ((eq button mouse-wheel-down-event)
> > >                  (condition-case nil (funcall mwheel-scroll-down-function amt)
> > >                    ;; Make sure we do indeed scroll to the beginning of
> > >                    ;; the buffer.
> > >                    (beginning-of-buffer
> > >                     (unwind-protect
> > >                         (funcall mwheel-scroll-down-function)
> > >                       ;; If the first scroll succeeded, then some scrolling
> > >                       ;; is possible: keep scrolling til the beginning but
> > >                       ;; do not signal an error.  For some reason, we have
> > >                       ;; to do it even if the first scroll signaled an
> > >                       ;; error, because otherwise the window is recentered
> > >                       ;; for a reason that escapes me.  This problem seems
> > >                       ;; to only affect scroll-down.  --Stef
> > >                       (set-window-start (selected-window) (point-min))))))
> > 
> > That is, when attempting to scroll down (as in, moving towards
> > beginning of buffer) under some mysterious circumstances, the window
> > gets recentered around point instead of being scrolled.  However, if
> > point is moved to the first line of the window, say, then the
> > scrolling does work as expected (as I've found out by experimenting
> > more with my initial recipe).
> 
> I have serious difficulties dealing with unexplained and undescribed
> problems that happen "under mysterious circumstances".
> 
> If you build with --enable-checking='yes,glyphs', and then turn on
> redisplay tracing with "M-x trace-redisplay" before scrolling with the
> wheel, what do you see?  And how does that trace differ from when you
> scroll with "M-1 M-v"?

Thanks, I will try that soon.  In the meantime, I noticed that I could
also reproduce the bug in Emacs 25.2, but not in 25.1.  I will try to
bisect between the releases.

> (I find it useful to disable blink-cursor-mode and global-eldoc-mode
> before such experiments, because they tend to trigger extra redisplay
> cycles that conceal the interesting parts.)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch (Charles A. Roelli)
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Mon, 20 Nov 2017 22:25:33 +0200

> Date: Mon, 20 Nov 2017 20:52:39 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> CC: 29325 <at> debbugs.gnu.org
> 
> I don't have access to a GNU/Linux system at the moment, but if I
> recall correctly, it would be 5 lines at a time, when scrolling
> slowly.

Then I'd expect the same behavior to happen if you do "M-5 M-v"
instead of turning the wheel.  Does it?

If M-v doesn't reproduce the problem, then what about removing the
tricky code, and leaving just

  (funcall mwheel-scroll-down-function amt)

without all the rest?  I cannot understand why we need the rest, maybe
I'm missing something.  mwheel-scroll-down-function is by default
scroll-down, exactly the same function called by M-v, so the results
should be the same, assuming that 'amt' is 5 when turning the wheel.

> The behavior is different depending on how fast the mouse wheel is
> turned.  If it is turned slowly several times in a row, it is possible
> to make window-start reach as far as the second or third line of the
> buffer.  If you turn it once more, then window-start jerks down a few
> lines instead of reaching the start of the buffer.  This can be
> repeated ad infinitum.
> 
> In contrast, when turning the mouse wheel quickly (a few notches in
> one second), it is not possible to get window-start anywhere near the
> start of the buffer, except by using non-mouse commands or by setting
> point closer to the top of the window first (with the mouse).

Just to make sure we are not barking up the wrong tree: this is in
"emacs -Q" with no customizations of any scroll-related variables,
like scroll-margin, scroll-conservatively, etc., right?

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

From: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Tue, 21 Nov 2017 20:24:05 +0100

> Date: Mon, 20 Nov 2017 22:25:33 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Mon, 20 Nov 2017 20:52:39 +0100
> > From: charles <at> aurox.ch (Charles A. Roelli)
> > CC: 29325 <at> debbugs.gnu.org
> > 
> > I don't have access to a GNU/Linux system at the moment, but if I
> > recall correctly, it would be 5 lines at a time, when scrolling
> > slowly.
> 
> Then I'd expect the same behavior to happen if you do "M-5 M-v"
> instead of turning the wheel.  Does it?

It does.

> Just to make sure we are not barking up the wrong tree: this is in
> "emacs -Q" with no customizations of any scroll-related variables,
> like scroll-margin, scroll-conservatively, etc., right?

Yes, always from emacs -q.

> Date: Sun, 19 Nov 2017 19:12:00 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> If you build with --enable-checking='yes,glyphs', and then turn on
> redisplay tracing with "M-x trace-redisplay" before scrolling with the
> wheel, what do you see?  And how does that trace differ from when you
> scroll with "M-1 M-v"?
> 
> (I find it useful to disable blink-cursor-mode and global-eldoc-mode
> before such experiments, because they tend to trigger extra redisplay
> cycles that conceal the interesting parts.)

Thanks again for this useful advice.  What follows is the annotated
output, according to the following recipe:

> The behavior is different depending on how fast the mouse wheel is
> turned.  If it is turned slowly several times in a row, it is possible
> to make window-start reach as far as the second or third line of the
> buffer.  If you turn it once more, then window-start jerks down a few
> lines instead of reaching the start of the buffer.  This can be
> repeated ad infinitum.

redisplay_internal 0 <= START FIRST SCROLL
0x1360330 (*info*): forced window start
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0
redisplay_internal 0 <= START SECOND SCROLL
0x1360330 (*info*): forced window start
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0 <= START THIRD SCROLL (BROKEN)
redisplay_internal 0
0x1360330 (*info*): recenter
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0

The third scroll should have reached the start of the buffer, but
recenters instead of doing so.

Furthermore, I found that reverting the following commit fixes the
issue locally, in a build of emacs-25:

* 9135bd7..: Paul Eggert 2016-05-13 Improve display of tex-verbatim and Info quoted
commit 9135bd7af7bdf9f805b185a77fe4e6d33dec4009
Author: Paul Eggert <eggert <at> cs.ucla.edu>
Date:   Fri May 13 13:30:33 2016 -0700

   Improve display of tex-verbatim and Info quoted

   Problem reported by Glenn Morris (Bug#19889).
   * doc/emacs/display.texi (Standard Faces):
   * doc/lispref/display.texi (Basic Faces):
   * etc/NEWS: Mention fixed-pitch-serif.
   * lisp/faces.el (face-font-family-alternatives):
   New family alias Monospace Serif.
   (fixed-pitch-serif): New face, which uses the new family.
   * lisp/info.el (Info-quoted):
   * lisp/textmodes/tex-mode.el (tex-verbatim): Use the new face.
   * test/lisp/legacy/font-parse-tests.el (font-parse-tests--data):
   Add test case for Monospace Serif.

   This is backport from master
   (cherry picked from commit 36906806ccfc0e53f1d8c365ab0d7151288b7833)

  doc/emacs/display.texi             |    3 +++
  doc/lispref/display.texi           |    1 +
  etc/NEWS                           |    5 +++++
  lisp/faces.el                      |   29 +++++++++++++++++++++++++++++
  lisp/info.el                       |    2 +-
  lisp/textmodes/tex-mode.el         |    3 +--
  test/automated/font-parse-tests.el |    1 +
  7 files changed, 41 insertions(+), 3 deletions(-)

So it may be that the new choice of fonts exposes a bug in the
scrolling mechanism.

Finally, I tried to make some analysis (by setting a breakpoint on
function "redisplay_window" in GDB) of why the recentering happens
while scrolling.  I then did the same analysis after having checked
out the commit prior to the problematic one, and compared the code
path.  It may well be of no use, but I include it here in case:

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.

try_to_scroll looks like this:

  try_to_scroll:

   /* Redisplay the mode line.  Select the buffer properly for that.  */
   if (!update_mode_line)
     {
       update_mode_line = true;
       w->update_mode_line = true;
     }

   if ((scroll_conservatively
        || emacs_scroll_step
        || temp_scroll_step
        || NUMBERP (BVAR (current_buffer, scroll_up_aggressively))
        || NUMBERP (BVAR (current_buffer, scroll_down_aggressively)))
       && CHARPOS (startp) >= BEGV
       && CHARPOS (startp) <= ZV)
     {
       /* The function returns -1 if new fonts were loaded, 1 if
	 successful, 0 if not successful.  */
       int ss = try_scrolling (window, just_this_one_p,
			      scroll_conservatively,
			      emacs_scroll_step,
			      temp_scroll_step, last_line_misfit);
       switch (ss)
	{
	case SCROLLING_SUCCESS:
	  goto done;

	case SCROLLING_NEED_LARGER_MATRICES:
	  goto need_larger_matrices;

	case SCROLLING_FAILED:
	  break;

	default:
	  emacs_abort ();
	}
     }

   /* Finally, just choose a place to start which positions point
      according to user preferences.  */

  recenter:

#ifdef GLYPH_DEBUG
   debug_method_add (w, "recenter");
#endif

   ...

However, these checks are all false during the scroll:

        (scroll_conservatively
        || emacs_scroll_step
        || temp_scroll_step
        || NUMBERP (BVAR (current_buffer, scroll_up_aggressively))
        || NUMBERP (BVAR (current_buffer, scroll_down_aggressively)))

so control falls through to the "recenter" label.

When I execute the same scroll command (from the same point and window
scroll state) in the commit prior to the problematic one, then the if
expression,

if (!cursor_row_fully_visible_p (w, false, false))

evaluates to false instead, control flow leads elsewhere, and the bug
does not happen.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch (Charles A. Roelli)
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Tue, 21 Nov 2017 21:42:59 +0200

> Date: Tue, 21 Nov 2017 20:24:05 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> CC: 29325 <at> debbugs.gnu.org
> 
> > Then I'd expect the same behavior to happen if you do "M-5 M-v"
> > instead of turning the wheel.  Does it?
> 
> It does.

Then let's abandon the wheel, and continue only with "M-5 M-v" from
now on.

> redisplay_internal 0 <= START FIRST SCROLL
> 0x1360330 (*info*): forced window start
> redisplay_preserve_echo_area (8)
> redisplay_internal 0
> redisplay_preserve_echo_area (8)
> redisplay_internal 0
> redisplay_internal 0
> redisplay_internal 0 <= START SECOND SCROLL
> 0x1360330 (*info*): forced window start
> redisplay_preserve_echo_area (8)
> redisplay_internal 0
> redisplay_preserve_echo_area (8)
> redisplay_internal 0
> redisplay_internal 0 <= START THIRD SCROLL (BROKEN)
> redisplay_internal 0
> 0x1360330 (*info*): recenter
> redisplay_preserve_echo_area (8)
> redisplay_internal 0
> redisplay_preserve_echo_area (8)
> redisplay_internal 0
> redisplay_internal 0
> 
> The third scroll should have reached the start of the buffer, but
> recenters instead of doing so.

Were you typing "M-5 M-v" or were you turning the mouse wheel?

> Furthermore, I found that reverting the following commit fixes the
> issue locally, in a build of emacs-25:
> 
> * 9135bd7..: Paul Eggert 2016-05-13 Improve display of tex-verbatim and Info quoted

Yes, but that doesn't help, the problem is not with selecting a
different font.

> 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.  The logic above fails
because it thinks we are at end of window, whereas we actually are at
or before the beginning of window.

> When I execute the same scroll command (from the same point and window
> scroll state) in the commit prior to the problematic one, then the if
> expression,
> 
> if (!cursor_row_fully_visible_p (w, false, false))
> 
> evaluates to false instead, control flow leads elsewhere, and the bug
> does not happen.

Which means that commit is not the culprit, it just exposes some
subtle bug.

Thanks for digging into this.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Tue, 21 Nov 2017 21:58:44 +0200

> Date: Tue, 21 Nov 2017 21:42:59 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 29325 <at> debbugs.gnu.org
> 
> > try_to_scroll looks like this:
> 
> I suspect we shouldn't go there in this case.  The logic above fails
> because it thinks we are at end of window, whereas we actually are at
> or before the beginning of window.

No, the last sentence is incorrect.  Nevertheless, something their
fails to work correctly because of how the various values involved
wind up, so I still want to see those values.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: 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,

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

From: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Wed, 22 Nov 2017 19:56:31 +0100

> Date: Tue, 21 Nov 2017 21:42:59 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Tue, 21 Nov 2017 20:24:05 +0100
> > From: charles <at> aurox.ch (Charles A. Roelli)
> > CC: 29325 <at> debbugs.gnu.org
> > 
> > > Then I'd expect the same behavior to happen if you do "M-5 M-v"
> > > instead of turning the wheel.  Does it?
> > 
> > It does.
> 
> Then let's abandon the wheel, and continue only with "M-5 M-v" from
> now on.

Ok.

> > redisplay_internal 0 <= START FIRST SCROLL
> > 0x1360330 (*info*): forced window start
> > redisplay_preserve_echo_area (8)
> > redisplay_internal 0
> > redisplay_preserve_echo_area (8)
> > redisplay_internal 0
> > redisplay_internal 0
> > redisplay_internal 0 <= START SECOND SCROLL
> > 0x1360330 (*info*): forced window start
> > redisplay_preserve_echo_area (8)
> > redisplay_internal 0
> > redisplay_preserve_echo_area (8)
> > redisplay_internal 0
> > redisplay_internal 0 <= START THIRD SCROLL (BROKEN)
> > redisplay_internal 0
> > 0x1360330 (*info*): recenter
> > redisplay_preserve_echo_area (8)
> > redisplay_internal 0
> > redisplay_preserve_echo_area (8)
> > redisplay_internal 0
> > redisplay_internal 0
> > 
> > The third scroll should have reached the start of the buffer, but
> > recenters instead of doing so.
> 
> Were you typing "M-5 M-v" or were you turning the mouse wheel?

This was with the wheel.  But the output when using "M-5 M-v" three
times in a row is equal, modulo some "redisplay_internal 0" lines.

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

Before the last line here is executed:

 > 	  if (new_vpos >= w->cursor.y)
 > 	    {
 > 	      w->cursor.vpos = -1;

we have,

(gdb) p new_vpos
$1 = 561
(gdb) p w->cursor.y
$2 = 557
(gdb) p w->cursor.vpos
$3 = 27

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

From: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Wed, 22 Nov 2017 20:04:26 +0100

> Date: Wed, 22 Nov 2017 17:38:26 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > > 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,

It certainly does on macOS, and I will test on GNU/Linux tomorrow.
Thanks a lot.

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

From: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29325 <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Thu, 23 Nov 2017 21:08:45 +0100

> Date: Wed, 22 Nov 2017 17:38:26 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > > 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,

I can confirm that it does fix the issue on GNU/Linux.  Thanks again
for your help here.

Message #55 received at 29325-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: charles <at> aurox.ch (Charles A. Roelli)
Cc: 29325-done <at> debbugs.gnu.org
Subject: Re: bug#29325: 26.0.90: Info scrolling stuck
Date: Thu, 23 Nov 2017 22:31:13 +0200

> Date: Thu, 23 Nov 2017 21:08:45 +0100
> From: charles <at> aurox.ch (Charles A. Roelli)
> CC: 29325 <at> debbugs.gnu.org
> 
> I can confirm that it does fix the issue on GNU/Linux.  Thanks again
> for your help here.

Thanks, pushed to the release branch.

Previous Next

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