bug#29325: 26.0.90: Info scrolling stuck

[Eli Zaretskii]

> Date: Tue, 21 Nov 2017 20:24:05 +0100
> From: charles@aurox.ch (Charles A. Roelli)
> CC: 29325@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.