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#22404: 25.1.50; Forcing `window-scroll-functions` to run. Date: Mon, 01 Feb 2016 21:54:42 +0200 Message-ID: <83vb68yznh.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1454357370 23650 80.91.229.3 (1 Feb 2016 20:09:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Feb 2016 20:09:30 +0000 (UTC) Cc: 22404@debbugs.gnu.org To: Keith David Bershatsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 01 21:09:16 2016 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 1aQKmg-0006sF-P5 for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Feb 2016 21:09:15 +0100 Original-Received: from localhost ([::1]:53962 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQKmc-0008AL-RE for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Feb 2016 15:09:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQKmZ-00089X-EW for bug-gnu-emacs@gnu.org; Mon, 01 Feb 2016 15:09:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQKmU-0003vu-JC for bug-gnu-emacs@gnu.org; Mon, 01 Feb 2016 15:09:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQKmU-0003vq-F6 for bug-gnu-emacs@gnu.org; Mon, 01 Feb 2016 15:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aQKmU-0000fx-Cx for bug-gnu-emacs@gnu.org; Mon, 01 Feb 2016 15:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Feb 2016 20:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22404 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22404-submit@debbugs.gnu.org id=B22404.14543573332570 (code B ref 22404); Mon, 01 Feb 2016 20:09:02 +0000 Original-Received: (at 22404) by debbugs.gnu.org; 1 Feb 2016 20:08:53 +0000 Original-Received: from localhost ([127.0.0.1]:55307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQKmK-0000fN-NY for submit@debbugs.gnu.org; Mon, 01 Feb 2016 15:08:52 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45167) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQKmJ-0000f4-Mt for 22404@debbugs.gnu.org; Mon, 01 Feb 2016 15:08:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQKZ0-0001ie-JO for 22404@debbugs.gnu.org; Mon, 01 Feb 2016 14:55:09 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQKZ0-0001iX-Ff; Mon, 01 Feb 2016 14:55:06 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1528 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aQKYy-0004At-I2; Mon, 01 Feb 2016 14:55:06 -0500 In-reply-to: (message from Keith David Bershatsky on Sun, 31 Jan 2016 19:50:05 -0800) 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:112225 Archived-At: > Date: Sun, 31 Jan 2016 19:50:05 -0800 > From: Keith David Bershatsky > Cc: 22404@debbugs.gnu.org,Michael Heerdegen > > I see that there are a few express circumstances in the function `window-end` where a forced update will not occur, even though a user expressly requested it with the optional argument being set to `t`. Michael had mentioned an unspecified situation where `window-end` was incorrect from the `window-scroll-functions` hook even with a forced update, so perhaps one or more of those expressly coded exceptions is/are to blame. I encountered a similar situation today in my testing with interactively calling `previous-line` at the top window edge (and scroll-conservatively 101) where the `window-end` was not updating correctly. > > Attached is a diff-patch of the second draft for the new proposed animal that is somewhat similar to the `window-scroll-functions` hook, but this new animal is able to run every command loop even when there is no scrolling. It automatically updates `window-end`, and it throws four (4) values that can be used by the user's custom function attached to the new hook: > > * window-start > * window-end > * point at the beginning of the line of window-start. > * point at the end of the line of window-end. > > I added two new symbols for the mode-line: little `%w` for `window-start` and big `%W` for `window-end`. This made debugging much easier, and I do a lot with window-start/end, so it comes in handy for writing other related functions. > > I removed one double quote in comments in `window.c` that was breaking my font-lock highlighting -- an unmatched double quotes in a comment always causes havoc with my highlighting for the remainder of the buffer, so I try to fix those whenever I come across them. > > I still haven't figured out how to entirely substitute throwing the switch `w->wsf_toggle = true` with just a buffer-local variable. Ideally, I would prefer that the new hook run whenever local variable `wsf-var` is `t` -- without needing a switch. At the present time, I am throwing the switch each command loop with the `post-command-hook`. [The switch gets set back to `false` during redisplay, and is needed as sort of a counter so that a section of the redisplay code does not run more than necessary.] > > This draft diff-patch can of course still use some polishing up -- e.g., the forced window update only needs to occur when `wsf-var` is `t`. In future drafts, I'll probably change some of the names to further distinguish this from the built-in WSF. [The built-in WSF section near a patched comment labeled "2 of 3" should probably now have an exception so that it doesn't run merely because this new animal is running, and I'll think some more about that in the coming days.] I'll be using this patch in my daily routine to see how it works out. Here is the sample usage, which is designed to be buffer-local: Keith, I appreciate all the efforts you are putting into this, but I'd rather we'd not go in that direction. Running Lisp from within the bowels of redisplay is inherently dangerous (because Lisp code can signal an error, which then makes Emacs not responsive due to infinite attempts to display the error message, which causes another error, etc.). Your patches add more places where we call Lisp, and in particular in places, like redisplay_window, where it simply is out of the question. I'd prefer to have a post-redisplay-hook, which is called either at the end of redisplay cycle, or after redisplay_internal returns to its caller. Would that solve your problem, and if so, what information do you need to be passed to such a hook? Thanks.