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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Alan Mackenzie <acm <at> muc.de>
Subject: bug#32874: closed (Re: bug#32874: Unwanted scrolling in edebug
 `f' command when follow-mode is active)
Date: Wed, 03 Oct 2018 11:01:02 +0000

[Message part 1 (text/plain, inline)]

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 32874 <at> debbugs.gnu.org.

-- 
32874: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32874
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Alan Mackenzie <acm <at> muc.de>
To: 32874-done <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Wed, 3 Oct 2018 10:54:42 +0000

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

[Message part 3 (message/rfc822, inline)]

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Unwanted scrolling in edebug `f' command when follow-mode is active
Date: Sat, 29 Sep 2018 14:09:57 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.