GNU bug report logs -
#14508
scroll-conservatively==1 not honored for fast line by line navigation up
Previous Next
Full log
Message #11 received at 14508 <at> debbugs.gnu.org (full text, mbox):
[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.