From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: moving point and scroll-conservatively Date: Sat, 26 Jun 2010 14:34:55 +0300 Message-ID: <83pqzec9i8.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1277552016 14594 80.91.229.12 (26 Jun 2010 11:33:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 26 Jun 2010 11:33:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 26 13:33:34 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OSTdd-0000hZ-CP for ged-emacs-devel@m.gmane.org; Sat, 26 Jun 2010 13:33:33 +0200 Original-Received: from localhost ([127.0.0.1]:56127 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OSTdc-0007zv-Ci for ged-emacs-devel@m.gmane.org; Sat, 26 Jun 2010 07:33:32 -0400 Original-Received: from [140.186.70.92] (port=46437 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OSTdV-0007zD-Dq for emacs-devel@gnu.org; Sat, 26 Jun 2010 07:33:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OSTdU-0006Qf-4Y for emacs-devel@gnu.org; Sat, 26 Jun 2010 07:33:25 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:45048) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OSTdT-0006Q8-Sq for emacs-devel@gnu.org; Sat, 26 Jun 2010 07:33:24 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L4M00H00DDTSH00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 26 Jun 2010 14:32:53 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.155.52]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L4M009C9DESBRO0@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 26 Jun 2010 14:32:53 +0300 (IDT) X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:126428 Archived-At: 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.)