bug#6671: moving point and scroll-conservatively

[Chong Yidong]

> Did any of you who set scroll-conservatively to most-positive-fixnum
> notice that moving around an unmodified buffer became much slower,
> since revno 100620, when point moves far away?
>
> This happens because the try_scrolling method would previously give up
> when point was more than 10 screen lines below the current end of the
> window.  Emacs would then perform a complete redisplay of the window,
> with point located on the middle line.  This "recentering" annoyed
> users who set scroll-conservatively to most-positive-fixnum, so revno
> 100620 modified try_scrolling to _never_ give up due to point being
> too far away, when scroll-conservatively is set to such a large value.
> However, try_scrolling is used not only for scroll commands such as
> the C-n or C-v, but for _any_ motion in a buffer that didn't change.
> Thus the unintended effect described above.

I don't think it's reasonable to make the iterator slog through
thousands of lines in an attempt to "scroll" general point motions.

Is the "unintended recentering" problem purely associated with the
commands next-line and previous-line?  If so, maybe we should
investigate ways to prevent point motion from "running ahead" of
redisplay in those specific instances.