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

[Eli Zaretskii <eliz@gnu.org>]

> Date:  Mon, 08 Feb 2016 00:51:44 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  22404@debbugs.gnu.org
> 
> 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'.

A reproducible recipe will be appreciated (in a separate bug report,
please).  I'm guessing that some redisplay optimization causes the
slightly inaccurate display, which is thereafter fixed.  If so, it
could be that the conditions for that optimization should be fixed.

> +        CALLN (Frun_hook_with_args, Qwindow_start_end_hook, window,
> +            make_number (startp_integer),
> +            make_number (endp),
> +            make_number (pbol_startp),
> +            make_number (peol_endp),
> +            fully_p ? Qt : Qnil);

When calling Lisp from redisplay, always use safe_call, to be
protected against errors signaled by that Lisp.

> +        w->window_start_end_hook_pending = false;

For the same reason, reset the flag _before_ calling Lisp, not after,
so that if Lisp does signal an error, the flag will be reset, and
won't cause the hook to be called ad nauseam.