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: charles <at> aurox.ch (Charles A. Roelli)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29325 <at> debbugs.gnu.org
Subject: 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).




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.