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

[Keith David Bershatsky]

Attached is the next in the series of draft concept ideas, which ensures the 
point is fully visible before firing.  Some people will naturally prefer that 
point be partially visible when the hook is triggered, but I like fully visible 
instead.

I noticed that redisplay handles a large yank/paste by erroneously letting the 
user see for a split second that point is partially visible on the bottom of 
the screen (when `scroll-conservatively` is 101), and then redisplay fixes the 
display by moving the lines up far enough to bring point back into view.  That 
behavior appears to be a bug -- i.e., Emacs should internally know that point 
is partially visible at the bottom of the screen following a large yank and 
then patiently wait to display the finished product until point is fully 
visible.  This is most noticeable in my own minor-mode that can take up to .040 
seconds to perform its calculations with `vertical-motion'.

The following is the proposed usage based on the attached concept draft 
patch/diff file:


(defun window-start-end-hook-fn (win start end pbol-start peol-end fully-p)
  (message "win: %s | start: %s | end: %s | pbol-start: %s | peol-end: %s | 
fully-p: %s"
    win start end pbol-start peol-end fully-p))

(setq window-start-end-hook-var t)

(setq scroll-conservatively 101)

(add-hook 'window-start-end-hook 'window-start-end-hook-fn nil t)

window_start_end_hook.diff
Description: application/diff