unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: emacs-devel@gnu.org
Subject: moving point and scroll-conservatively
Date: Sat, 26 Jun 2010 14:34:55 +0300	[thread overview]
Message-ID: <83pqzec9i8.fsf@gnu.org> (raw)

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



             reply	other threads:[~2010-06-26 11:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-26 11:34 Eli Zaretskii [this message]
2010-06-26 11:52 ` moving point and scroll-conservatively Juanma Barranquero
2010-06-26 12:25   ` Eli Zaretskii
2010-06-26 13:08     ` David De La Harpe Golden
2010-06-26 14:08       ` Christoph
2010-06-26 21:25     ` Juanma Barranquero
2010-06-28 21:08     ` Juri Linkov
2010-06-26 12:44 ` David De La Harpe Golden
2010-07-19 12:48 ` Juanma Barranquero
2010-07-19 17:39   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83pqzec9i8.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).