From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#18739: 24.3; Request for a hook to be provided when scrolling will move the cursor Date: Thu, 16 Oct 2014 15:28:23 -0400 Message-ID: References: <83wq813vyx.fsf@gnu.org> <83r3y84iuv.fsf@gnu.org> <831tq83xwq.fsf@gnu.org> <83r3y82ep3.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1413487781 30921 80.91.229.3 (16 Oct 2014 19:29:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Oct 2014 19:29:41 +0000 (UTC) Cc: josh+gnu@nispio.net, 18739@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 16 21:29:34 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xeqjt-00015G-0n for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Oct 2014 21:29:33 +0200 Original-Received: from localhost ([::1]:52311 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xeqjs-0007lu-K3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Oct 2014 15:29:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeqjV-0007Md-Pz for bug-gnu-emacs@gnu.org; Thu, 16 Oct 2014 15:29:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XeqjO-0001Mh-Aw for bug-gnu-emacs@gnu.org; Thu, 16 Oct 2014 15:29:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XeqjO-0001Md-6c for bug-gnu-emacs@gnu.org; Thu, 16 Oct 2014 15:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XeqjN-0000O1-Nm for bug-gnu-emacs@gnu.org; Thu, 16 Oct 2014 15:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Oct 2014 19:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18739 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18739-submit@debbugs.gnu.org id=B18739.14134877061440 (code B ref 18739); Thu, 16 Oct 2014 19:29:01 +0000 Original-Received: (at 18739) by debbugs.gnu.org; 16 Oct 2014 19:28:26 +0000 Original-Received: from localhost ([127.0.0.1]:46218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xeqio-0000NA-7V for submit@debbugs.gnu.org; Thu, 16 Oct 2014 15:28:26 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58568) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xeqim-0000Mw-0v for 18739@debbugs.gnu.org; Thu, 16 Oct 2014 15:28:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNFxKjo/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASUYpQ3gWqBcYFbIQ X-IPAS-Result: ArUGAIDvNVNFxKjo/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASUYpQ3gWqBcYFbIQ X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="94378497" Original-Received: from 69-196-168-232.dsl.teksavvy.com (HELO pastel.home) ([69.196.168.232]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2014 15:28:23 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 169E885A2; Thu, 16 Oct 2014 15:28:23 -0400 (EDT) In-Reply-To: <83r3y82ep3.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 16 Oct 2014 18:54:00 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:94643 >> So, could we say that this hook is supposed to be run if and only if >> the window-start marker is changed? > I don't think so, because set-window-buffer and split-window-internal > run the hook unconditionally, i.e. they don't check whether the > window-start changed. If the marker used to point into another buffer, it is clearly changed, so the only problem is that the hook may be run a few more times than necessary, e.g. if you set-window-buffer to the buffer that's already displayed in that window. I think this "definition" of the behavior of window-scroll-functions is more useful/precise. >> E.g. it is not called if the only change is that text has been >> inserted before window-start (hence the numeric value of >> window-start would be changed, but the marker still points to the >> same place). > As long as the old window-start is valid and point is in view, I don't > think the hook will be called, no. Good. Consistent with my definition. > But note that inserting text before window-start could cause > scrolling, if window-start was originally in a continued line, or if > text was added at the beginning of the line that was the window-start. Right, in which case window-start would be modified by the redisplay in order to perform the scrolling and window-scroll-functions would be run, right? So, again, consistent with my definition. >> And as for "when" it is run: any time after the marker's modification >> and before updating the glyph matrices? > Yes. >> Is it run before or after computing the new mode-line > Before. Good, thanks. >> Do you happen to know where is the C code that changes point >> (in response to scrolling) in the redisplay? > The part that begins under the force_start label in redisplay_window, > and is conditioned by the window's force_start flag. Right, I see it (in xdisp.c) after the comment that says: /* If we need to move point for either of the above reasons, now actually do it. */ Playing with it, I see that this code is triggered very rarely. `scroll-up' doesn't go through this at all. We also "set point in response to scrolling" in window_scroll_line_based and in window_scroll_pixel_based. There might be others. >> Yes, thanks. I still don't really understand how/why follow-mode and >> em-smart.el work, tho. > Who does? ;-) I think I'm beginning to understand why follow-mode's use of window-scroll-functions works most of the time. I think it relies on the fact that it will first be called on window W1 even though the window it cares about is W2, so it gets to (set-window-start W2 (point-max)) before redisplay gets a chance to change W2's window-start, and afterwards, redisplay can't do that because of force_start. And this "sticks" long enough to end a redisplay cycle. Stefan