GNU bug report logs - #14508
scroll-conservatively==1 not honored for fast line by line navigation up

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 14508 in the body.
You can then email your comments to 14508 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: Barry OReilly <gundaetiapo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: scroll-conservatively==1 not honored for fast line by line navigation
	up
Date: Wed, 29 May 2013 18:58:33 -0400

[Message part 1 (text/plain, inline)]

Let /tmp/scroll-conservatively-1.el have this content:

  (setq scroll-conservatively 1)
  (add-hook 'term-setup-hook (lambda () (goto-char (point-max))))

And /tmp/foo.cpp as attached.

Also set the keyboard repitition rate somewhat high.

Start Emacs by: emacs -Q /tmp/foo.cpp --load /tmp/scroll-conservatively-1.el

Hold arrow up key, recentering occurs while scrolling up.

Note: Script goes to EOB because I only witness this for scroll ups, not
scroll downs.

I witness this regularly when navigating C++ source code.

----

In GNU Emacs 24.3.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.4)
 of 2013-05-23 on redacted
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
System Description:    Red Hat Enterprise Linux Client release 5.4 (Tikanga)

Configured using:
 `configure --prefix=/redacted/user/boreilly/sw/emacs-install-trunk
 --with-gif=no'

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: C++/l

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

Recent input:
M-x r e p o r t - e m a c <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
foo.cpp has auto save data; consider M-x recover-this-file
Loading cc-langs...done

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message cl-macs gv 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 mail-prsvr mail-utils cc-langs cl nadvice cl-lib cc-mode
cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs time-date tooltip 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 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 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 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

[Message part 2 (text/html, inline)]

[foo.cpp (text/x-c++src, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Barry OReilly <gundaetiapo <at> gmail.com>
Cc: 14508 <at> debbugs.gnu.org
Subject: Re: bug#14508: scroll-conservatively==1 not honored for fast line by
	line	navigation up
Date: Sat, 01 Jun 2013 16:11:07 +0300

> Date: Wed, 29 May 2013 18:58:33 -0400
> From: Barry OReilly <gundaetiapo <at> gmail.com>
> 
> Let /tmp/scroll-conservatively-1.el have this content:
> 
>   (setq scroll-conservatively 1)
>   (add-hook 'term-setup-hook (lambda () (goto-char (point-max))))
> 
> And /tmp/foo.cpp as attached.
> 
> Also set the keyboard repitition rate somewhat high.
> 
> Start Emacs by: emacs -Q /tmp/foo.cpp --load /tmp/scroll-conservatively-1.el
> 
> Hold arrow up key, recentering occurs while scrolling up.
> 
> Note: Script goes to EOB because I only witness this for scroll ups, not
> scroll downs.
> 
> I witness this regularly when navigating C++ source code.

This is normal.  Sometimes, Emacs redisplay takes more time, for
various reasons (e.g., garbage collection triggered by JIT font-lock
that fontifies portions of text that come into view).  When redisplay
finishes, Emacs finds more than a single keystroke in its keyboard
queue, and processes all of them, which moves point more than 1 line
out of the window.  Since scroll-conservatively is set to 1, Emacs
recenters.

You see this on scroll ups, because they are slightly slower than
scroll downs, and the difference is enough to trigger this with higher
probability when you go up.

To avoid this, set scroll-conservatively to higher values.  For
example, I just set it to 3 and was able to scroll through the whole
file you sent without even a single recenter.

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

From: Barry OReilly <gundaetiapo <at> gmail.com>
Cc: 14508 <at> debbugs.gnu.org
Subject: Re: bug#14508: scroll-conservatively==1 not honored for fast line by
	line navigation up
Date: Fri, 7 Jun 2013 12:37:08 -0400

[Message part 1 (text/plain, inline)]

> You see this on scroll ups, because they are slightly slower than
> scroll downs, and the difference is enough to trigger this with
> higher probability when you go up.

Closely related, I define these commands (byte compiled):

  (defvar my-leap-scroll-size 16)
  (define-key evil-normal-state-map ";" nil)
  (define-key evil-motion-state-map ";"
    (lambda ()
      (interactive)
      (scroll-up my-leap-scroll-size)
      (evil-next-line my-leap-scroll-size)))
  (define-key evil-normal-state-map "'" nil)
  (define-key evil-motion-state-map "'"
    (lambda ()
      (interactive)
      (scroll-down my-leap-scroll-size)
      (evil-previous-line my-leap-scroll-size)))

In the same C++ buffer as before, when I hold to repeat the above
command that scrolls up*, the display doesn't update at all until I
release the key to stop the repeat. As you indicated it may, the
scroll down can keep up in this case. I turned font locking off and
the scroll up redisplay keeps up. I also tried this in a Python buffer
with font lock on and these commands keep up much better. Is it that
the C/C++ font locking is more complex? Has C/C++ major mode been
performance tuned for this use case? Maybe I can experiment with my
local configuration to temporarily disable font locking while I'm
scrolling up fast -- seeing non font locked code fly by would be
better than nothing at all.

* Assume I use "up" and "down" in the majority usage, opposite of
  Emacs terminology

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Barry OReilly <gundaetiapo <at> gmail.com>
Cc: 14508 <at> debbugs.gnu.org
Subject: Re: bug#14508: scroll-conservatively==1 not honored for fast line by
	line	navigation up
Date: Fri, 07 Jun 2013 22:27:51 +0300

> Date: Fri, 7 Jun 2013 12:37:08 -0400
> From: Barry OReilly <gundaetiapo <at> gmail.com>
> Cc: 14508 <at> debbugs.gnu.org
> 
> In the same C++ buffer as before, when I hold to repeat the above
> command that scrolls up*, the display doesn't update at all until I
> release the key to stop the repeat. As you indicated it may, the
> scroll down can keep up in this case. I turned font locking off and
> the scroll up redisplay keeps up. I also tried this in a Python buffer
> with font lock on and these commands keep up much better. Is it that
> the C/C++ font locking is more complex?

Could be, I wouldn't know (and don't use Python enough to share my
experience).

> Has C/C++ major mode been
> performance tuned for this use case? Maybe I can experiment with my
> local configuration to temporarily disable font locking while I'm
> scrolling up fast -- seeing non font locked code fly by would be
> better than nothing at all.

I'd suggest to try activating jit-lock-stealth and/or jit-lock-defer
instead.  These two features should make the problem less acute, once
you tune the customization parameters, jit-lock-stealth-time and
jit-lock-defer-time, correspondingly.

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

From: Barry OReilly <gundaetiapo <at> gmail.com>
To: 14508-done <at> debbugs.gnu.org
Subject: scroll-conservatively==1 not honored for fast line by line navigation
 up
Date: Thu, 13 Feb 2014 15:17:00 -0500

[Message part 1 (text/plain, inline)]

I ended up settling on settings:

 '(font-lock-maximum-decoration (quote ((c++-mode . 2))))
 '(scroll-conservatively 101)
 '(scroll-margin 4)

and in the C++ mode hook:

  (setq jit-lock-defer-time 0.01)

So I am able to scroll through C++ buffers with timely redisplays and
without recenterings. Closing.

[Message part 2 (text/html, inline)]

Previous Next

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