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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Sep 29, 2018 at 19:09:00 +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 Sep 2018 15:37:29 +0000
> > Cc: 32874@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

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

> > Thanks!  I'll have a look at pre-redisplay-function, and see if I can do
> > anything with it.

This was surprisingly easy.  I've got a follow-mode function on
pre-redisplay-function in place of the post-command-hook function, and
it seems to be working.  In particular, edebug's `f' now moves to the
next window without spurious scrolling.

The code badly needs tidying up, though.  ;-)

> I'd actually urge you to have a good look at window-scroll-functions
> as well.  (Follow mode already uses it, but I think it could use it
> for quite a lot more.)  This hook is called when Emacs concludes that
> a window may need to be scrolled to bring point into view.  This is
> exactly where Follow mode wants to be able to affect the decision of
> the display engine, right?  I think by making a few simple
> changes/extensions where this hook is called, we could make the work
> of Follow mode quite a lot easier, by letting it rely on the display
> engine instead of trying to maneuver the display engine to do what it
> wants.

I've had a look at window-scroll-functions, but I can't see what you
must be seeing.  Currently, the documentation warns against trying to
influence the scrolling, saying "it probably won't work anyway".

Maybe it would be relatively simple to introduce new functionality.
Something like "scroll window so that window-end gets the given value".
This would likely be easier to implement in the display engine than the
rather clumsy iterative "point and shoot" approximations in follow.el.
Maybe.

-- 
Alan Mackenzie (Nuremberg, Germany).