emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#32874: closed (Unwanted scrolling in edebug `f' co


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#32874: closed (Unwanted scrolling in edebug `f' command when follow-mode is active)
Date: Wed, 03 Oct 2018 11:01:01 +0000

Your message dated Wed, 3 Oct 2018 10:54:42 +0000
with message-id <address@hidden>
and subject line Re: bug#32874: Unwanted scrolling in edebug `f' command when 
follow-mode is active
has caused the debbugs.gnu.org bug report #32874,
regarding Unwanted scrolling in edebug `f' command when follow-mode is active
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
32874: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32874
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Unwanted scrolling in edebug `f' command when follow-mode is active Date: Sat, 29 Sep 2018 14:09:57 +0000 User-agent: Mutt/1.10.1 (2018-07-13)
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).



--- End Message ---
--- Begin Message --- Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when follow-mode is active Date: Wed, 3 Oct 2018 10:54:42 +0000 User-agent: Mutt/1.10.1 (2018-07-13)
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).


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]