bug#22404: 25.1.50; Forcing `window-scroll-functions` to run.

[Eli Zaretskii]

> Date:  Sun, 31 Jan 2016 19:50:05 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22404@debbugs.gnu.org,Michael Heerdegen <eliz@gnu.org>
> 
> 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.