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

Previous Next

Package: emacs;

Reported by: Barry OReilly <gundaetiapo <at> gmail.com>

Date: Wed, 29 May 2013 23:01:02 UTC

Severity: normal

Done: Barry OReilly <gundaetiapo <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Barry OReilly <gundaetiapo <at> gmail.com>
Cc: 14508 <at> debbugs.gnu.org
Subject: 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)]

This bug report was last modified 11 years and 157 days ago.

Previous Next


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