From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24179: 25.1; scroll-conservatively over SCROLL_LIMIT may put point in the wrong place Date: Fri, 12 Aug 2016 17:17:19 +0300 Message-ID: <83k2fmdqc0.fsf@gnu.org> References: <87y448s2k8.fsf@gmail.com> <83vazchtm2.fsf@gnu.org> <8737mfyfxy.fsf@gmail.com> <83shufi8er.fsf@gnu.org> <87r39zkyli.fsf@gmail.com> <83fuqfi4e9.fsf@gnu.org> <87invbkwfe.fsf@gmail.com> <83inv7fiq5.fsf@gnu.org> <87fuqb3q3s.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1471011900 19881 195.159.176.226 (12 Aug 2016 14:25:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 12 Aug 2016 14:25:00 +0000 (UTC) Cc: 24179@debbugs.gnu.org To: Alex Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 12 16:24:55 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bYDOH-0004uH-4c for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Aug 2016 16:24:53 +0200 Original-Received: from localhost ([::1]:52387 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYDOE-0007jD-3A for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Aug 2016 10:24:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYDIt-0002yb-D2 for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2016 10:19:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYDIa-0008PH-NU for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2016 10:19:18 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYDIa-0008P4-J0 for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2016 10:19:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bYDIb-0001u8-K3 for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2016 10:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Aug 2016 14:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24179 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24179-submit@debbugs.gnu.org id=B24179.14710115357303 (code B ref 24179); Fri, 12 Aug 2016 14:19:01 +0000 Original-Received: (at 24179) by debbugs.gnu.org; 12 Aug 2016 14:18:55 +0000 Original-Received: from localhost ([127.0.0.1]:55260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bYDIV-0001tj-1F for submit@debbugs.gnu.org; Fri, 12 Aug 2016 10:18:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bYDIT-0001tX-Nm for 24179@debbugs.gnu.org; Fri, 12 Aug 2016 10:18:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYDHv-0007ql-AB for 24179@debbugs.gnu.org; Fri, 12 Aug 2016 10:18:47 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47126) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYDHM-0007KA-Hx; Fri, 12 Aug 2016 10:17:44 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3806 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bYDHI-00058i-Li; Fri, 12 Aug 2016 10:17:43 -0400 In-reply-to: <87fuqb3q3s.fsf@gmail.com> (message from Alex on Thu, 11 Aug 2016 16:20:07 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:122123 Archived-At: tags 24179 fixed close 24179 quit > From: Alex > Cc: 24179@debbugs.gnu.org > Date: Thu, 11 Aug 2016 16:20:07 -0600 > > >> You're right, though it also seems to happen when using C-n. I tried > >> turning off line-move-visual and the delay is still there. > > > > I have now fixed that problem as well. > > Thanks, I don't see it anymore with C-n. It's expected that the delay > with M-g c and magit-blame's `n' command is still present, right? I don't see any perceptible delay here, but maybe I missed something. Do some "M-g c" work faster than others? Or some other motion commands are faster than "M-g c 1350 RET"? If so, can you give a recipe for a "fast" and a "slow" command? In general, setting scroll-conservatively to a large value makes redisplay slightly slower, because in some situations it must work harder to find the smallest possible scroll amount. If a before-string inserted by magit-blame uses up many screen lines, the fix I added might indeed cause a slowdown, although they'll have to be quite a lot of screen lines for that to become perceptible, I think. Another potential reason for slower redisplay, specific to magit-blame and similar modes, is that a significant proportion of lines in a typical window comes from overlay strings, not from buffer text. When Emacs needs to determine the position of window-start for next redisplay, it starts from point and goes back till it finds a suitable buffer position, which would put point some specific number of pixels from the window-start. When Emacs goes back, it uses the number of lines in the buffer as the first approximation, then adjusts that place as needed. With many display or overlay strings in a window, that first approximation is usually way off, so the process of adjusting it to find the correct place needs to consider more potential candidates, and this takes longer. > Though your new commit does seem to lessen those delays, if that means > anything. The original delay was not a delay. What happened is that the first redisplay after "M-g c 1350 RET" would end up with point off the screen, and the cursor at the end of the first screen line. Immediately after that another redisplay would fix that by scrolling the window. So it took 2 redisplay cycles to react to the command; now it takes only one. > > OK. If no new issues come up due to my changes, please close the bug > > in a few days. > > Hopefully the above did that. No, it didn't. When you include control commands in a message, you should BCC control@debbugs.gnu.org for the bug tracker to take notice (like I did with tis message). If you want to just close the bug (as opposed to add some tags), an easier way is to CC 24179-done@debbugs.gnu.org. Thanks.