--- Begin Message ---
|
Subject: |
moving point and scroll-conservatively |
|
Date: |
Mon, 19 Jul 2010 22:25:28 +0200 |
Package: emacs
Severity: important
Version: 24.0.50
---------- Forwarded message ----------
From: Eli Zaretskii <address@hidden>
Date: Sat, Jun 26, 2010 at 13:34
Subject: moving point and scroll-conservatively
To: address@hidden
Did any of you who set scroll-conservatively to most-positive-fixnum
notice that moving around an unmodified buffer became much slower,
since revno 100620, when point moves far away?
For example, with this recipe:
emacs -Q
M-: (setq scroll-conservatively most-positive-fixnum scroll-step 0) RET
C-x C-f xdisp.c
C-u 25000 M-g M-g
it takes Emacs 17 seconds on my 3GHz machine to display xdisp.c around
line 25000, whereas it's instantaneous in Emacs 23.2.
This happens because the try_scrolling method would previously give up
when point was more than 10 screen lines below the current end of the
window. Emacs would then perform a complete redisplay of the window,
with point located on the middle line. This "recentering" annoyed
users who set scroll-conservatively to most-positive-fixnum, so revno
100620 modified try_scrolling to _never_ give up due to point being
too far away, when scroll-conservatively is set to such a large value.
However, try_scrolling is used not only for scroll commands such as
the C-n or C-v, but for _any_ motion in a buffer that didn't change.
Thus the unintended effect described above.
I guess we should limit try_scrolling to situations where at least one
screen line from the previous display is left on the screen.
Otherwise, we are going to redisplay the entire window anyway, and
this optimization does not make sense. Note that the documentation of
scroll-conservatively explicitly says "set it to some small number N";
i.e. it was never the intent that it will be set to such large values.
For the same reason the value of the scroll-*-aggressively variables
is limited to 1.
The resulting recentering when Emacs cannot keep up with the keyboard
auto-repeat rate caused by user leaning on the down arrow should be
handled in some different way (see my suggestion in the "The
unwarranted scrolling assumption" thread).
Btw, what do users of scroll-conservatively = most-positive-fixnum
want from C-v and PageDown keys? Is it okay to recenter in that case,
or do you want to see the cursor on the last screen line in that case
as well? (Emacs does not currently distinguish between these two
cases. In fact, it does not care at all which command caused point to
move.)
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#6671: moving point and scroll-conservatively |
|
Date: |
Thu, 31 Mar 2011 21:19:35 +0200 |
> From: Juanma Barranquero <address@hidden>
> Date: Tue, 29 Mar 2011 01:00:00 +0200
> Cc: address@hidden, address@hidden
>
> On Sun, Mar 27, 2011 at 05:59, Eli Zaretskii <address@hidden> wrote:
>
> > That's good to hear. Please see if it still works great after fixing
> > a stupid mistake with parentheses (see my other mail this morning).
>
> Yes, it works great. Please install it.
Done (in revision 103792 on the trunk).
I'm closing this bug, because I think it has been beaten to death. If
there are any left-overs, or new bugs I introduced, please file new
bug reports.
--- End Message ---