bug#6671: moving point and scroll-conservatively

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> These change you propose would also necessitate reverting 100619/100620.
> Anytime the iterator is forced to traverse thousands (or in this case
> tens of thousands) of lines, that's clearly the wrong thing.

Well, "the wrong thing" in the sense of "obviously not what the user
intended", anyway.  I agree that the changes you made cause the
redisplay engine to literally follow the documented meaning of
scroll-conservatively.

Here's a more concrete proposal.  We change scroll-conservatively to
accept a new value, t, which means "scroll as far as you need".  Then
try_scrolling can use the "try scrolling for 10 lines" heuristic before
failing.  In this specific case, a failure changes centering_position,
adjusting the window start as though we had really scrolled the full
amount.

However, it's become idiomatic to set scroll-conservatively to a large
number.  Users of that idiom, who haven't changed scroll-conservatively
to t, would remain affected by the performance hit.  To cope with this,
let's change the meaning of numeric values of scroll-conservatively: if
it's larger than (say) 300, that is equivalent to t (infinity).

What do you think?