GNU bug report logs - #22404
25.1.50; Forcing `window-scroll-functions` to run.

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Keith David Bershatsky <esq <at> lawlist.com>
Cc: johnw <at> gnu.org, 22404 <at> debbugs.gnu.org
Subject: bug#22404: 25.1.50; Forcing `window-scroll-functions` to run.
Date: Fri, 29 Jan 2016 10:42:25 +0200

> Date:  Thu, 28 Jan 2016 19:08:22 -0800
> From:  Keith David Bershatsky <esq <at> lawlist.com>
> Cc:  22404 <at> debbugs.gnu.org,Eli Zaretskii <eliz <at> gnu.org>
> 
> Let's say for example that someone has a function named `foo` which uses `window-start` and `window-end`, and the user wants that function to run every command loop.  Everyone will immediately think of the `post-command-hook` because the buffer or position may have been modified by `this-command` (whatever that may be).  The way Emacs is presently designed, people are needlessly calling `foo` multiple times when scrolling occurs because the `post-command-hook` can't provide correct numbers.

Personally, I think that having a function run by post-command-hook
that crucially depends on window-start and window-end is poor design.
Emacs never promised that these values be accurate before redisplay
runs, since redisplay sometimes needs to change where the window
starts and ends.

Solving this with window-scroll-functions is not the proper solution,
either, for the reasons already discussed at length in this thread.

I still don't understand well enough why pre-command-hook is not a
better solution here.  Until I do, I don't see how this issue can be
resolved better than it is today.  I don't like exposing APIs that
manipulate flags which are there for internal machinery.  Lisp
programs that set these flags arbitrarily can easily disrupt the
redisplay operation, so such APIs is a time bomb.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.