Subject: bug#32874: closed (Re: bug#32874: Unwanted scrolling in edebug `f' command when follow-mode is active)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 03 Oct 2018 11:01:02 +0000

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
32874: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32874
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when follow-mode is active
From: Alan Mackenzie <[email-masked]>
To: [email-masked]
Date: Wed, 3 Oct 2018 10:54:42 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

On Sun, Sep 30, 2018 at 14:45:29 +0000, Alan Mackenzie wrote:
> Any objection from anybody to me committing this change to master?

Bug fixed, by commiting the change from my previous post.

-- 
Alan Mackenzie (Nuremberg, Germany).

Subject: Unwanted scrolling in edebug `f' command when follow-mode is active
From: Alan Mackenzie <[email-masked]>
To: [email-masked]
Date: Sat, 29 Sep 2018 14:09:57 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

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).