bug#19464: 24.4; Customizing either scroll-step or scroll-conservatively makes Emacs hang up when calling set-window-vscroll with large values

bug#19464: 24.4; Customizing either scroll-step or scroll-conservatively makes Emacs hang up when calling set-window-vscroll with large values

[Vasilij Schneidermann]

[-- Attachment #1: Type: text/plain, Size: 3410 bytes --]

I've been experimenting around to make Emacs scroll with pixel-level
precision and have soon discovered `set-window-vscroll' which allows one
to adjust the vertical scrolling of a window in pixel steps with its
fourth argument.  In an attempt to scroll further than a screenful, I
executed (set-window-vscroll nil 9000 t) which hung up Emacs.  Bisection
of my init file revealed that this issue doesn't happen with an
uncustomized Emacs and that it's sufficient to either customize
`scroll-step' to have a value of 1 or `scroll-conservatively' to have a
large value (which is a common hack to allow line-level scrolling).  Is
this interaction a bug?  If not, can it at the very least be documented
in the docstring of `set-window-vscroll'?



In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.3)
 of 2014-10-21 on bitzer.hoetzel.info
Windowing system distributor `The X.Org Foundation', version 11.0.11603000
System Description: Arch Linux

Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o <tab> <down-mouse-2> <mouse-2>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
/usr/share/emacs/site-lisp/SuperCollider/tree-widget hides
/usr/share/emacs/24.4/lisp/tree-widget

Features:
(shadow sort gnus-util mail-extr emacsbug message idna format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils help-mode easymenu time-date
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 74922 7762)
 (symbols 48 17669 0)
 (miscs 40 80 138)
 (strings 32 9343 4421)
 (string-bytes 1 257939)
 (vectors 16 9064)
 (vector-slots 8 385359 16597)
 (floats 8 65 302)
 (intervals 56 227 4)
 (buffers 960 13)
 (heap 1024 41177 904))

[-- Attachment #2: Type: text/html, Size: 3836 bytes --]

bug#19464: 24.4; Customizing either scroll-step or scroll-conservatively makes Emacs hang up when calling set-window-vscroll with large values

[Vasilij Schneidermann]

Bump.

bug#19464: 24.4; Customizing either scroll-step or scroll-conservatively makes Emacs hang up when calling set-window-vscroll with large values

[Lars Ingebrigtsen]

Vasilij Schneidermann <v.schneidermann@gmail.com> writes:

> I've been experimenting around to make Emacs scroll with pixel-level
> precision and have soon discovered `set-window-vscroll' which allows one
> to adjust the vertical scrolling of a window in pixel steps with its
> fourth argument.  In an attempt to scroll further than a screenful, I
> executed (set-window-vscroll nil 9000 t) which hung up Emacs.  Bisection
> of my init file revealed that this issue doesn't happen with an
> uncustomized Emacs and that it's sufficient to either customize
> `scroll-step' to have a value of 1 or `scroll-conservatively' to have a
> large value (which is a common hack to allow line-level scrolling).

(I'm going through old bug reports that unfortunately got no response at
the time.)

I tried reproducing this with

emacs -Q and:

(progn
  (setq scroll-step 1)
  (set-window-vscroll nil 9000 t))

But I didn't get any hangs.  Are you still seeing this problem in more
recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19464: 24.4; Customizing either scroll-step or scroll-conservatively makes Emacs hang up when calling set-window-vscroll with large values

[Vasilij Schneidermann]

Yes, I do. My reproducer relies on having a file spanning more than a
screenful open.

- Run `emacs -Q`
- Paste the following code block into the scratch buffer
- Evaluate with `M-x buffer`

(find-library "subr")
(setq scroll-conservatively 10000)
(set-window-vscroll nil 9000 t)

On Fri, May 28, 2021 at 3:43 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Vasilij Schneidermann <v.schneidermann@gmail.com> writes:
>
> > I've been experimenting around to make Emacs scroll with pixel-level
> > precision and have soon discovered `set-window-vscroll' which allows one
> > to adjust the vertical scrolling of a window in pixel steps with its
> > fourth argument.  In an attempt to scroll further than a screenful, I
> > executed (set-window-vscroll nil 9000 t) which hung up Emacs.  Bisection
> > of my init file revealed that this issue doesn't happen with an
> > uncustomized Emacs and that it's sufficient to either customize
> > `scroll-step' to have a value of 1 or `scroll-conservatively' to have a
> > large value (which is a common hack to allow line-level scrolling).
>
> (I'm going through old bug reports that unfortunately got no response at
> the time.)
>
> I tried reproducing this with
>
> emacs -Q and:
>
> (progn
>   (setq scroll-step 1)
>   (set-window-vscroll nil 9000 t))
>
> But I didn't get any hangs.  Are you still seeing this problem in more
> recent Emacs versions?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

bug#19464: 24.4; Customizing either scroll-step or scroll-conservatively makes Emacs hang up when calling set-window-vscroll with large values

[Eli Zaretskii]

> From: Vasilij Schneidermann <v.schneidermann@gmail.com>
> Date: Mon, 31 May 2021 18:41:04 +0200
> Cc: 19464@debbugs.gnu.org
> 
> Yes, I do. My reproducer relies on having a file spanning more than a
> screenful open.
> 
> - Run `emacs -Q`
> - Paste the following code block into the scratch buffer
> - Evaluate with `M-x buffer`
> 
> (find-library "subr")
> (setq scroll-conservatively 10000)
> (set-window-vscroll nil 9000 t)

Emacs doesn't hang, it's just that redisplay becomes extremely
sluggish with these settings after certain commands.  If you turn off
blink-cursor-mode and global-eldoc-mode (which induce additional
redisplay cycles, and thus create an illusion of a hang) before
setting the two variables, you will see that after several dozens of
seconds Emacs finishes redisplay with this huge vscroll and can
perform further commands, albeit with some of them responding slowly.

The problem here is that you on the one hand ask the display engine to
be very accurate when scrolling the window, so that not even a single
text line is scrolled into the view unless it's necessary to show
point; and OTOH you force point to be very far outside the viewport.
Whet the display engine does in response is (slowly and inefficiently)
finding how to deal with this contradiction.

IOW: Emacs gave you a rope and you've succeeded to hang yourself with
it.

If we think that this result is not what should be expected in this
situation, then what should be expected?  Should we somehow detect the
huge vscroll and limit it? or disallow scroll-conservatively in this
case? or something else?

In general, vscroll was introduced to support display of stuff that is
too tall to fit in the window: tall images and very large fonts.
Here, it seems you are trying to use it to force point out of the
viewport, and the question I have is: what for, and what you expect
Emacs to do in this barely supported situation?

bug#19464: 24.4; Customizing either scroll-step or scroll-conservatively makes Emacs hang up when calling set-window-vscroll with large values

[Lars Ingebrigtsen]

Vasilij Schneidermann <v.schneidermann@gmail.com> writes:

> Yes, I do. My reproducer relies on having a file spanning more than a
> screenful open.
>
> - Run `emacs -Q`
> - Paste the following code block into the scratch buffer
> - Evaluate with `M-x buffer`

Did you mean `M-x eval-buffer'?

> (find-library "subr")
> (setq scroll-conservatively 10000)
> (set-window-vscroll nil 9000 t)

If so, I'm still not able to reproduce the problem on this
Debian/bullseye laptop -- `M-x eval-buffer' here takes less than half a
second for me in Emacs 28 and Emacs 27.1.

What Emacs/OS versions are you using?  And are there any missing steps
in the recipe?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19464: 24.4; Customizing either scroll-step or scroll-conservatively makes Emacs hang up when calling set-window-vscroll with large values

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> If so, I'm still not able to reproduce the problem on this
> Debian/bullseye laptop -- `M-x eval-buffer' here takes less than half a
> second for me in Emacs 28 and Emacs 27.1.
>
> What Emacs/OS versions are you using?  And are there any missing steps
> in the recipe?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no