bug#6671: moving point and scroll-conservatively

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: lekktu@gmail.com, 6671@debbugs.gnu.org
> Date: Thu, 24 Mar 2011 16:01:46 -0400
> 
> 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.

I didn't mean for the code to do what it does now, and certainly
didn't interpret scroll-conservatively to mean that.  It was an
accident: I simply didn't realize that arbitrary movement of point
will invoke try_scrolling.  I thought we only get there for scrolling
commands, like next-line and scroll-up/down.  I intend to fix this.

> 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?

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).
Maybe after I try that, I will come to a conclusion that what I
suggest is unworkable, but until then, I don't think we should
consider such radical changes.

Please let me work on this for a few days.  This bug is present on the
trunk for a very long time, and it was never an issue until now (in
fact, its first report came from me, even though I don't use
scroll-conservatively).  Given that, I don't see any urgency today, it
can well wait for a few more days.