moving point and scroll-conservatively

moving point and scroll-conservatively

[Eli Zaretskii]

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.)

Re: moving point and scroll-conservatively

[Juanma Barranquero]

On Sat, Jun 26, 2010 at 13:34, Eli Zaretskii <eliz@gnu.org> wrote:

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

No, I hadn't noticed.

> it takes Emacs 17 seconds on my 3GHz machine to display xdisp.c around
> line 25000, whereas it's instantaneous in Emacs 23.2.

It takes ~10s on my 2.5GHz Core2Quad Q9300. Which is ~10s longer than
it takes in 23.2, yes :-(

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

The documentation is in conflict because, as I already pointed out,
the docstring for `scroll-step' clearly says:

  If you want scrolling to always be a line at a time, you should set
  `scroll-conservatively' to a large value rather than set this to 1.

which is what prompted me to set it to most-positive-fixnum in the
first place. Perhaps, once the implementation is working as expected,
we should simply add an option scroll-never-recenter or somesuch.

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

IIUC, if PgDown recenters, PgDown/PgUp will no longer be a noop (I set
`scroll-preserve-screen-position' to `always'), which would be pretty
bad.

All in all, I would prefer for Emacs *never* recenter unless I ask it
explicitly via C-l.

Thanks for all the hard work on this issue.

    Juanma

Re: moving point and scroll-conservatively

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 26 Jun 2010 13:52:17 +0200
> Cc: emacs-devel@gnu.org
> 
> All in all, I would prefer for Emacs *never* recenter unless I ask it
> explicitly via C-l.

Not even for "M-g M-g"?

Re: moving point and scroll-conservatively

[David De La Harpe Golden]

On 26/06/10 12:34, Eli Zaretskii wrote:
> 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.
>

Yes, that does appear slow, though taking ~ 10 seconds on my machine.

> 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.)
>

Well ... scroll-preserve-screen-position?  That seems to be working 
anyway on pgup/dn, the point stays on the same screen line and I don't 
see recentering.

Re: moving point and scroll-conservatively

[David De La Harpe Golden]

On 26/06/10 13:25, Eli Zaretskii wrote:
>> From: Juanma Barranquero<lekktu@gmail.com>
>> Date: Sat, 26 Jun 2010 13:52:17 +0200
>> Cc: emacs-devel@gnu.org
>>
>> All in all, I would prefer for Emacs *never* recenter unless I ask it
>> explicitly via C-l.
>
> Not even for "M-g M-g"?
>

Recentering there probably not all that obnoxious as it's something of
a clean break situation.  But preserve-screen-position might be nicer if 
achievable in that situation too.

Re: moving point and scroll-conservatively

[Christoph]

On 6/26/2010 7:08 AM, David De La Harpe Golden wrote:
>> Not even for "M-g M-g"?
>>
> Recentering there probably not all that obnoxious as it's something of
> a clean break situation. But preserve-screen-position might be nicer if
> achievable in that situation too.

I agree. Could "M-g M-g" look at scroll-preserve-screen-position to know 
when to do this? nil would recenter, t or any other value would preserve 
the screen position. To me, "M-g M-g" is somewhat of a scroll command.

Christoph

Re: moving point and scroll-conservatively

[Juanma Barranquero]

On Sat, Jun 26, 2010 at 14:25, Eli Zaretskii <eliz@gnu.org> wrote:

> Not even for "M-g M-g"?

No, of course I don't mind M-g M-g recentering. I only object to
recentering during scrolling (be line-by-line or page-by-page); that's
why I proposed `scroll-dont-recenter', not `move-point-dont-recenter'
:-)

    Juanma

Re: moving point and scroll-conservatively

[Juri Linkov]

>> All in all, I would prefer for Emacs *never* recenter
>> unless I ask it explicitly via C-l.
>
> Not even for "M-g M-g"?

I think that it should respect non-nil value of
`scroll-preserve-screen-position'.  And when this is
not possible, or when `scroll-preserve-screen-position' is nil
then it could use the first element of `recenter-positions'
so the user will be able to configure the default vertical
recentering position.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: moving point and scroll-conservatively

[Juanma Barranquero]

On Sat, Jun 26, 2010 at 13:34, Eli Zaretskii <eliz@gnu.org> wrote:

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

Should we file a bug report for this so it is not forgotten*?

    Juanma


* Hardly, as it is quite noticeable, but still...

Re: moving point and scroll-conservatively

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 19 Jul 2010 14:48:37 +0200
> Cc: emacs-devel@gnu.org
> 
> On Sat, Jun 26, 2010 at 13:34, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > 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?
> 
> Should we file a bug report for this so it is not forgotten*?

Yes, thanks.