bug#6671: moving point and scroll-conservatively

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

>> 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.
>
> What does that mean, in terms of behavior?

This means that any time point moves below the bottom of the window, the
resulting scroll will leave the cursor at the bottom of the window.  Any
time point moves above the top of the window, the resulting scroll will
leave the cursor at the top of the window.  Unlike numerical values of
scroll-conservatively, there is no "scrolling limit" to check.

>> 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).
>
> That's a bit hackish. IMHO, if you do change `scroll-conservatively'
> as suggested, just document the new values and let people change it.

Hackish yes, but if there is no real reason to specify such big
numerical values, I don't see any way this could have bad effects, in
practice.  Otherwise, users who miss that NEWS entry might get
frustrated by the sluggish behavior.

Another possibility is to introduce a "scroll-conservatively-scan-limit"
variable, instead of hardcoding 300 lines.