Subject: bug#14508: scroll-conservatively==1 not honored for fast line by line navigation up

From: Eli Zaretskii <[email-masked]>
Date: Sat, 01 Jun 2013 16:11:07 +0300

> Date: Wed, 29 May 2013 18:58:33 -0400
> From: Barry OReilly <[email-masked]>
> 
> 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.