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

[Keith David Bershatsky <esq@lawlist.com>]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

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)



[-- Attachment #2: window_start_end_hook.diff --]
[-- Type: application/diff, Size: 10910 bytes --]