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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32874 in the body.
You can then email your comments to 32874 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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

Message #8 received at 32874 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 32874 <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Sat, 29 Sep 2018 17:35:43 +0300

> Date: Sat, 29 Sep 2018 14:09:57 +0000
> From: Alan Mackenzie <acm <at> muc.de>
> 
> 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.

What is the reason for calling sit-for?  Can the call to sit-for be
replaced with something else when follow-mode is in effect and we
aren't in the last window of the follow group?

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

Actually, redisplay-hook is not well defined, because different
potential customers of such a hook would like that hook to be called
from different parts of the redisplay cycle and under different
conditions.  Thus we have pre-redisplay-function instead, and a few
other specialized hooks the display engine calls, like
window-scroll-functions.

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

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

Message #11 received at 32874 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32874 <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Sat, 29 Sep 2018 15:37:29 +0000

Hello, Eli.

On Sat, Sep 29, 2018 at 17:35:43 +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 Sep 2018 14:09:57 +0000
> > From: Alan Mackenzie <acm <at> muc.de>

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

> What is the reason for calling sit-for?  Can the call to sit-for be
> replaced with something else when follow-mode is in effect and we
> aren't in the last window of the follow group?

sit-for is called right after (edebug-overlay-arrow), I think, to ensure
that the newly placed arrow is actually drawn on the screen.

I can't think of any replacement for this sit-for at the moment.

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

> Actually, redisplay-hook is not well defined, because different
> potential customers of such a hook would like that hook to be called
> from different parts of the redisplay cycle and under different
> conditions.  Thus we have pre-redisplay-function instead, and a few
> other specialized hooks the display engine calls, like
> window-scroll-functions.

OK, that sounds like a good reason for not having such a hook.  :-(

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #14 received at 32874 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 32874 <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Sat, 29 Sep 2018 19:09:00 +0300

> Date: Sat, 29 Sep 2018 15:37:29 +0000
> Cc: 32874 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> 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.

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.

Message #17 received at 32874 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32874 <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Sat, 29 Sep 2018 20:41:13 +0000

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 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> 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).

Message #20 received at 32874 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 32874 <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Sun, 30 Sep 2018 10:35:50 +0300

> Date: Sat, 29 Sep 2018 20:41:13 +0000
> Cc: 32874 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > 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".

But you don't want to scroll yourself, you just want to switch the
selected window and move point so that Emacs won't need to scroll.

AFAIU, follow-mode wants to kick in when point goes off the selected
window.  And the call to window-scroll-functions is exactly the place
where the display engine decides it needs to scroll the window, but
didn't actually scroll it yet.  So that looks like a good place to
have follow-mode do its thing.  We might need to add some simple
facility for follow-mode to use, so that it could signal the display
engine not to scroll the window.  Other than that, I think this
possibility is worth exploring.

The advantage of using window-scroll-functions is that
pre-redisplay-function is called much more frequently, in most cases
follow-mode will need to do nothing at all.  You probably already have
a logic for detecting when it should do something, but if you are
invoked from window-scroll-functions, most if not all of that logic
will be redundant.

> Maybe it would be relatively simple to introduce new functionality.
> Something like "scroll window so that window-end gets the given value".

I'm not sure I understand how this could help follow-mode.  Please
elaborate.

Message #23 received at 32874 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32874 <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Sun, 30 Sep 2018 14:45:29 +0000

Hello, yet again, Eli.

On Sat, Sep 29, 2018 at 17:35:43 +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 Sep 2018 14:09:57 +0000
> > From: Alan Mackenzie <acm <at> muc.de>

[ .... ]

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

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

Indeed, pre-redisplay-function appears to work well.  The following
patch, which moves follow-mode's embedding in Emacs from
post-command-hook to pre-redisplay-function appears to solve the
original bug (Unwanted scrolling after `f' in edebug) completely.

Any objection from anybody to me committing this change to master?


diff --git a/lisp/follow.el b/lisp/follow.el
index 7aa7b51473..54ece9cd4f 100644
--- a/lisp/follow.el
+++ b/lisp/follow.el
@@ -187,8 +187,8 @@
 ;; Implementation:
 ;;
 ;; The main method by which Follow mode aligns windows is via the
-;; function `follow-post-command-hook', which is run after each
-;; command.  This "fixes up" the alignment of other windows which are
+;; function `follow-pre-redisplay-function', which is run before each
+;; redisplay.  This "fixes up" the alignment of other windows which are
 ;; showing the same Follow mode buffer, on the same frame as the
 ;; selected window.  It does not try to deal with buffers other than
 ;; the buffer of the selected frame, or windows on other frames.
@@ -418,7 +418,8 @@ follow-mode
   (if follow-mode
       (progn
 	(add-hook 'compilation-filter-hook 'follow-align-compilation-windows t t)
-	(add-hook 'post-command-hook 'follow-post-command-hook t)
+        ;; (add-hook 'post-command-hook 'follow-post-command-hook t)
+        (add-function :before pre-redisplay-function 'follow-pre-redisplay-function)
 	(add-hook 'window-size-change-functions 'follow-window-size-change t)
         (add-hook 'after-change-functions 'follow-after-change nil t)
         (add-hook 'isearch-update-post-hook 'follow-post-command-hook nil t)
@@ -445,7 +446,7 @@ follow-mode
 	(setq following (buffer-local-value 'follow-mode (car buffers))
 	      buffers (cdr buffers)))
       (unless following
-	(remove-hook 'post-command-hook 'follow-post-command-hook)
+	;; (remove-hook 'post-command-hook 'follow-post-command-hook)
 	(remove-hook 'window-size-change-functions 'follow-window-size-change)))
 
     (kill-local-variable 'move-to-window-group-line-function)
@@ -1260,10 +1261,27 @@ follow-avoid-tail-recenter
 	    (not (eq win top))))  ;; Loop while this is true.
       (set-buffer orig-buffer))))
 
-;;; Post Command Hook
+;;; Pre Display Function
+
+;; This function is added to `pre-display-function' and is thus called
+;; before each redisplay operation.  It supersedes (2018-09) the
+;; former use of the post command hook, and now does the right thing
+;; when a program calls `redisplay' or `sit-for'.
+
+(defun follow-pre-redisplay-function (wins)
+  (if (or (eq wins t)
+          (null wins)
+          (and (listp wins)
+               (memq (selected-window) wins)))
+      (follow-post-command-hook)))
 
-;; The magic little box. This function is called after every command.
+;;; Post Command Hook
 
+;; The magic little box. This function was formerly called after every
+;; command.  It is now called before each redisplay operation (see
+;; `follow-pre-redisplay-function' above), and at the end of several
+;; search/replace commands.  It retains its historical name.
+;;
 ;; This is not as complicated as it seems. It is simply a list of common
 ;; display situations and the actions to take, plus commands for redrawing
 ;; the screen if it should be unaligned.
@@ -1284,6 +1302,12 @@ follow-post-command-hook
 	  (setq follow-windows-start-end-cache nil))
         (follow-adjust-window win)))))
 
+;; NOTE: to debug follow-mode with edebug, it is helpful to add
+;; `follow-post-command-hook' to `post-command-hook' temporarily.  Do
+;; this locally to the target buffer with, say,:
+;; M-: (add-hook 'post-command-hook 'follow-post-command-hook t t)
+;; .
+
 (defun follow-adjust-window (win)
   ;; Adjust the window WIN and its followers.
   (cl-assert (eq (window-buffer win) (current-buffer)))


-- 
Alan Mackenzie (Nuremberg, Germany).

Message #26 received at 32874 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32874 <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Sun, 30 Sep 2018 15:36:46 +0000

Hello, Eli.

On Sun, Sep 30, 2018 at 10:35:50 +0300, Eli Zaretskii wrote:
> > Date: Sat, 29 Sep 2018 20:41:13 +0000
> > Cc: 32874 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

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

> But you don't want to scroll yourself, you just want to switch the
> selected window and move point so that Emacs won't need to scroll.

> AFAIU, follow-mode wants to kick in when point goes off the selected
> window.  And the call to window-scroll-functions is exactly the place
> where the display engine decides it needs to scroll the window, but
> didn't actually scroll it yet.  So that looks like a good place to have
> follow-mode do its thing.  We might need to add some simple facility
> for follow-mode to use, so that it could signal the display engine not
> to scroll the window.  Other than that, I think this possibility is
> worth exploring.

Follow-mode also needs to be active on explicit scrolling commands such
as C-v.  Also, after inserting a newline, subsequent windows need to be
scrolled down.  After either of these, follow-mode laboriously starts
determining where all its windows have to start and end.  There's nothing
in the display engine to help in this process.

> The advantage of using window-scroll-functions is that
> pre-redisplay-function is called much more frequently, in most cases
> follow-mode will need to do nothing at all.  You probably already have
> a logic for detecting when it should do something, but if you are
> invoked from window-scroll-functions, most if not all of that logic
> will be redundant.

> > Maybe it would be relatively simple to introduce new functionality.
> > Something like "scroll window so that window-end gets the given value".

> I'm not sure I understand how this could help follow-mode.  Please
> elaborate.

Currently when a middle or right hand window gets scrolled for any
reason, follow-mode has to determine how to scroll windows to the left of
it.  It does this by making a first guess at a window-start, does
set-window-start, then moves forward through the window to see how close
window-end is to where it needs to be.  If it's a line off, a different
starting position is chosen, and so on, until window-start gets correctly
placed.

If there were a function set-window-end, the display engine itself could
move back over the text lines to find window-start far more efficiently
and directly than follow-mode can.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #29 received at 32874 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 32874 <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Sun, 30 Sep 2018 20:17:46 +0300

> Date: Sun, 30 Sep 2018 15:36:46 +0000
> Cc: 32874 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > > 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".
> 
> > But you don't want to scroll yourself, you just want to switch the
> > selected window and move point so that Emacs won't need to scroll.
> 
> > AFAIU, follow-mode wants to kick in when point goes off the selected
> > window.  And the call to window-scroll-functions is exactly the place
> > where the display engine decides it needs to scroll the window, but
> > didn't actually scroll it yet.  So that looks like a good place to have
> > follow-mode do its thing.  We might need to add some simple facility
> > for follow-mode to use, so that it could signal the display engine not
> > to scroll the window.  Other than that, I think this possibility is
> > worth exploring.
> 
> Follow-mode also needs to be active on explicit scrolling commands such
> as C-v.  Also, after inserting a newline, subsequent windows need to be
> scrolled down.  After either of these, follow-mode laboriously starts
> determining where all its windows have to start and end.  There's nothing
> in the display engine to help in this process.

I'm not sure you are right, since all of the situations you describe
go through the function try_scrolling, which calls
window-scroll-functions.

> > > Maybe it would be relatively simple to introduce new functionality.
> > > Something like "scroll window so that window-end gets the given value".
> 
> > I'm not sure I understand how this could help follow-mode.  Please
> > elaborate.
> 
> Currently when a middle or right hand window gets scrolled for any
> reason, follow-mode has to determine how to scroll windows to the left of
> it.  It does this by making a first guess at a window-start, does
> set-window-start, then moves forward through the window to see how close
> window-end is to where it needs to be.  If it's a line off, a different
> starting position is chosen, and so on, until window-start gets correctly
> placed.
> 
> If there were a function set-window-end, the display engine itself could
> move back over the text lines to find window-start far more efficiently
> and directly than follow-mode can.

It should be very easy to write such a function, provided that you can
pass it as argument the buffer position of the beginning of the last
line in the window (not the end of that line).

Message #32 received at 32874 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32874 <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Mon, 1 Oct 2018 12:59:22 +0000

Hello, Eli.

On Sun, Sep 30, 2018 at 20:17:46 +0300, Eli Zaretskii wrote:
> > Date: Sun, 30 Sep 2018 15:36:46 +0000
> > Cc: 32874 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

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

> > > But you don't want to scroll yourself, you just want to switch the
> > > selected window and move point so that Emacs won't need to scroll.

> > > AFAIU, follow-mode wants to kick in when point goes off the selected
> > > window.  And the call to window-scroll-functions is exactly the place
> > > where the display engine decides it needs to scroll the window, but
> > > didn't actually scroll it yet.  So that looks like a good place to have
> > > follow-mode do its thing.  We might need to add some simple facility
> > > for follow-mode to use, so that it could signal the display engine not
> > > to scroll the window.  Other than that, I think this possibility is
> > > worth exploring.

> > Follow-mode also needs to be active on explicit scrolling commands such
> > as C-v.  Also, after inserting a newline, subsequent windows need to be
> > scrolled down.  After either of these, follow-mode laboriously starts
> > determining where all its windows have to start and end.  There's nothing
> > in the display engine to help in this process.

> I'm not sure you are right, since all of the situations you describe
> go through the function try_scrolling, which calls
> window-scroll-functions.

I have the feeling we're at cross purposes somehow, here.  I think the
display engine, by itself, is only ever going to be scrolling the
selected window.  Some mechanism is needed for scrolling the other follow
windows to synchronise with the selected window.  Currently, follow-mode
does all this calculation, neither elegantly nor efficiently.  I don't
think there is anything in the display manager to help with this.

Are you suggesting that the scrolling of the other follow windows could
somehow be assisted, possibly even triggered, by a call of
window-scroll-functions from the selected window?

> > > > Maybe it would be relatively simple to introduce new functionality.
> > > > Something like "scroll window so that window-end gets the given value".

> > > I'm not sure I understand how this could help follow-mode.  Please
> > > elaborate.

> > Currently when a middle or right hand window gets scrolled for any
> > reason, follow-mode has to determine how to scroll windows to the left of
> > it.  It does this by making a first guess at a window-start, does
> > set-window-start, then moves forward through the window to see how close
> > window-end is to where it needs to be.  If it's a line off, a different
> > starting position is chosen, and so on, until window-start gets correctly
> > placed.

> > If there were a function set-window-end, the display engine itself could
> > move back over the text lines to find window-start far more efficiently
> > and directly than follow-mode can.

> It should be very easy to write such a function, provided that you can
> pass it as argument the buffer position of the beginning of the last
> line in the window (not the end of that line).

That sounds very strange.  Where would the difficulty lie in the display
engine doing (forward-line -1) rather than the Lisp code?

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #35 received at 32874 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 32874 <at> debbugs.gnu.org
Subject: Re: bug#32874: Unwanted scrolling in edebug `f' command when
 follow-mode is active
Date: Mon, 01 Oct 2018 16:52:40 +0300

> Date: Mon, 1 Oct 2018 12:59:22 +0000
> Cc: 32874 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > > Follow-mode also needs to be active on explicit scrolling commands such
> > > as C-v.  Also, after inserting a newline, subsequent windows need to be
> > > scrolled down.  After either of these, follow-mode laboriously starts
> > > determining where all its windows have to start and end.  There's nothing
> > > in the display engine to help in this process.
> 
> > I'm not sure you are right, since all of the situations you describe
> > go through the function try_scrolling, which calls
> > window-scroll-functions.
> 
> I have the feeling we're at cross purposes somehow, here.  I think the
> display engine, by itself, is only ever going to be scrolling the
> selected window.

I'm saying that by using window-scroll-functions you can catch _any_
scrolling, and control what happens when the display engine wants to
scroll.

But I'm not selling anything.  You said many times that you wished the
display engine did part of the job in follow-mode, and that
follow-mode could use some help from the display engine.  I think by
using window-scroll-functions you can get some of that, but if you
don't see how, it's fine with me.

> > > Currently when a middle or right hand window gets scrolled for any
> > > reason, follow-mode has to determine how to scroll windows to the left of
> > > it.  It does this by making a first guess at a window-start, does
> > > set-window-start, then moves forward through the window to see how close
> > > window-end is to where it needs to be.  If it's a line off, a different
> > > starting position is chosen, and so on, until window-start gets correctly
> > > placed.
> 
> > > If there were a function set-window-end, the display engine itself could
> > > move back over the text lines to find window-start far more efficiently
> > > and directly than follow-mode can.
> 
> > It should be very easy to write such a function, provided that you can
> > pass it as argument the buffer position of the beginning of the last
> > line in the window (not the end of that line).
> 
> That sounds very strange.  Where would the difficulty lie in the display
> engine doing (forward-line -1) rather than the Lisp code?

forward-line goes back one physical line, not one screen line.

It isn't rocket science to start with the largest buffer position in
the window, it's just a bit more complicated, so if we can start from
the beginning of the screen line, it will make the job very easy.

Message #40 received at 32874-done <at> debbugs.gnu.org (full text, mbox):

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

Previous Next

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