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

[Alan Mackenzie]

Hello, Emacs.

Start an edebug session in some Emacs Lisp source code, where the
follow-mode is enabled for the .el buffer, and that buffer is displayed
in at least two windows.

Scroll the .el buffer until some sexp is split across two windows.  When
the execution point reaches this sexp, press f `edebug-forward-sexp'.

What one sees is the left hand window wrongly scrolls upwards to display
the end of the sexp, where point is left.  This is wrong.  Point ought to
move the end of the sexp in the right hand window, without any scrolling.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

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.

This (sit-for 0) calls redisplay, and this redisplay call bypasses the
follow-mode manipulation, which is in a post-command-hook.

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.

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.

The obvious solution would be to implement `redisplay-hook'.  Since this
is so obvious, yet wasn't done several decades ago, there are probably
reasons for not doing it.

Has anybody got any ideas for fixing this?

-- 
Alan Mackenzie (Nuremberg, Germany).