[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6671: moving point and scroll-conservatively

From: Chong Yidong
Subject: bug#6671: moving point and scroll-conservatively
Date: Thu, 24 Mar 2011 17:36:36 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]