bug#6671: moving point and scroll-conservatively

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> I would like to try fixing that code along the lines I suggested in a
> previous mail.  That looks like the best alternative, since it doesn't
> have any user-level changes (except for the bug that it should fix).

The solution you suggested was:

> when point is "far away" (which could be set back to those proverbial
> 10 screen lines), then, instead of moving one line at a time, move to
> point in one go, and then compute the window start so that point is at
> the proper place relative to window start.

If the current literal meaning of scroll-conservatively is retained, we
need to count the number of lines involved in performing this "far-away
scroll", by iterating.  That brings us back to square one.

Think about it this way: suppose scroll-conservatively is 200000.  Taken
literally, this means that if we move point 200000 (screen) lines down,
redisplay should leave the cursor at the bottom of the window; if we
move point 200001 (screen) lines down, redisplay should recenter.  There
is only one way to determine the number of screen lines between the
bottom of our current window and the new value of point: a big expensive
redisplay iteration.

If you want to avoid this pitfall, your solution and mine become the
same, i.e. special handling of "sufficiently large" values of
scroll-conservatively.