From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#6671: moving point and scroll-conservatively Date: Thu, 24 Mar 2011 03:23:44 -0400 Message-ID: References: <87vcz9s60m.fsf@stupidchicken.com> <87tyetb258.fsf@stupidchicken.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1300952242 19490 80.91.229.12 (24 Mar 2011 07:37:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 24 Mar 2011 07:37:22 +0000 (UTC) Cc: lekktu@gmail.com, 6671@debbugs.gnu.org To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 24 08:37:17 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Q2f6a-0004L2-C9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Mar 2011 08:37:16 +0100 Original-Received: from localhost ([127.0.0.1]:44469 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2f6Z-0000Hr-PX for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Mar 2011 03:37:15 -0400 Original-Received: from [140.186.70.92] (port=59343 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2f6S-0000HL-9m for bug-gnu-emacs@gnu.org; Thu, 24 Mar 2011 03:37:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2f6Q-0003zm-TC for bug-gnu-emacs@gnu.org; Thu, 24 Mar 2011 03:37:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q2f6Q-0003zi-QK for bug-gnu-emacs@gnu.org; Thu, 24 Mar 2011 03:37:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Q2etm-0006Zu-5M; Thu, 24 Mar 2011 03:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Mar 2011 07:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6671 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6671-submit@debbugs.gnu.org id=B6671.130095143225271 (code B ref 6671); Thu, 24 Mar 2011 07:24:02 +0000 Original-Received: (at 6671) by debbugs.gnu.org; 24 Mar 2011 07:23:52 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q2etc-0006ZY-9P for submit@debbugs.gnu.org; Thu, 24 Mar 2011 03:23:52 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q2eta-0006ZM-6u for 6671@debbugs.gnu.org; Thu, 24 Mar 2011 03:23:50 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Q2etU-00085t-Hi; Thu, 24 Mar 2011 03:23:44 -0400 In-reply-to: <87tyetb258.fsf@stupidchicken.com> (message from Chong Yidong on Wed, 23 Mar 2011 23:58:27 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 24 Mar 2011 03:24:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:45312 Archived-At: > From: Chong Yidong > Date: Wed, 23 Mar 2011 23:58:27 -0400 > Cc: 6671@debbugs.gnu.org > > After playing around with the "C-n in xdisp.c" testcase with the changes > in revision 100619/100620 reverted, I think I know the problem. > > In this test case, recentering seems to be triggered by redisplay-time > fontification. To demonstrat this, set fontification-functions to nil > in xdisp.c, before initiating the C-n testcase. For me, at least, the > anomalous recentering then does not occur. Sorry, but phenomenological explanations shouldn't be accepted in this case. We need specific evidence, and the only way to show that is by adding the necessary tracing code and showing the results. For example, I suggest to try introducing artificial delays (with `nanosleep' or some such) into redisplay, and trying then, with fontification-functions disabled. You may find out (as I did at the time) that fontification is just a trigger, not the cause itself; the cause is more computations done during redisplay, which cause the display engine bail out prematurely (unless you turn on redisplay-dont-pause), which is yet another cause of recentering. > The precise mechanism by which the fontification functions screw things > up is by narrowing the buffer. This is why, in last year's thread, the > buffer's clip_changed flag was found to be set. That forces recentering > in redisplay_window (xdisp.c:14159). Well, it shouldn't. Instead of "fixing" the code by preventing this flag to be set based on some heuristics, we should make the code DTRT even if the flag is set (assuming that this indeed is the root cause of the recentering in its all incarnations, which I'm not sure about). Please note that I'm not convinced that the issue of fontification and the clip_changed flag is relevant to the issue at hand. Recentering has more than one reason, so you could be seeing one of the other ones. We shouldn't mix them, if we want to remain sane and leave our display code maintainable. > So, a good fix might be to check whether redisplay-time fontification > changes the buffer's restrictions, and, if so, reset the clip_changed > flag. That should make the 100619/100620 changes unnecessary. Please don't revert these changes. They took a lot of effort to arrive at, and generally DTRT in a way that is easy to understand and maintain. The problem with performance for large moves of point is IMO straightforward to fix: when point is "far away" (which could be set back to those proverbial 10 screen lines), then, instead of moving one line at a time, move to point in one go, and then compute the window start so that point is at the proper place relative to window start. That proper place depends on the variables that try_scrolling considers already, like scroll-conservatively etc. The problem is, it considers them too early, before we realize that point is too far away. When we do realize that, we are already past the code that computes the scroll according to those variables, and all we do is punt and recenter. So the fix would be to re-arrange the code in try_scrolling so that the decision to move far away and the move itself are done _before_ we consider the adjustments of window start according to the scroll-related variables. IOW, we are suffering from historical legacy in redisplay here. Originally, Emacs always recentered. Then the various scrolling options were introduced, but the code is still structured so that it eventually falls back on recentering. We should change that so that whatever happens, after catching up with point we compute the window start according to user expectations expressed through the scroll-* options. That would eliminate the recentering fallback completely, and finally put this issue to rest.