bug#32874: Unwanted scrolling in edebug `f' command when follow-mode is active

[Eli Zaretskii]

> Date: Sat, 29 Sep 2018 14:09:57 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> The immediate cause of this is at edebug--recursive-edit L+86, where
> there is a call to (sit-for 0).  If this call is commented out, and the
> bug scenario repeated, there is no spurious scrolling.  That call is
> there for a reason, however, so this isn't a fix for the bug.

What is the reason for calling sit-for?  Can the call to sit-for be
replaced with something else when follow-mode is in effect and we
aren't in the last window of the follow group?

> The use of post-command-hook for follow mode is clearly suboptimal.
> Follow mode is essentially a part of redisplay, so it ought to get called
> from a redisplay hook.  The trouble is, `redisplay-hook' doesn't exist.

Actually, redisplay-hook is not well defined, because different
potential customers of such a hook would like that hook to be called
from different parts of the redisplay cycle and under different
conditions.  Thus we have pre-redisplay-function instead, and a few
other specialized hooks the display engine calls, like
window-scroll-functions.

> The best available hooks which might serve seem to be
> pre-redisplay-function or pre-redisplay-functions.  Unfortunately, these
> are called too late, after redisplay has already determined which windows
> to operate on.

That's not true: pre-redisplay-function is called _before_ the display
engine determines what window(s) might need to be redrawn.