GNU bug report logs - #51210
Customizable other-window-for-scrolling

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Thu, 14 Oct 2021 17:23:02 UTC

Severity: normal

Fixed in version 29.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 17:23:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Juri Linkov <juri <at> linkov.net>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 14 Oct 2021 17:23:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 20:19:44 +0300
Often scroll-other-window uses a wrong window for scrolling
when there are more than 2 windows on the frame.

Maybe like there is a variable other-window-scroll-buffer,
it would be nice to add a new user option
other-window-for-scrolling-function that will return
a window for scrolling.  It could provide a choise list that
includes a function that returns the most-recently-used window.

Then maybe also minibuffer-handling logic could be moved from
other-window-for-scrolling to the function used by default
in this new option.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 17:32:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 20:31:17 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 14 Oct 2021 20:19:44 +0300
> 
> Often scroll-other-window uses a wrong window for scrolling
> when there are more than 2 windows on the frame.

Which one is the "right" window?

And can you show a recipe for the issue?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 17:34:02 GMT) Full text and rfc822 format available.

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

From: <jakanakaevangeli <at> chiru.no>
To: Juri Linkov <juri <at> linkov.net>, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 19:37:20 +0200
Juri Linkov <juri <at> linkov.net> writes:

> Often scroll-other-window uses a wrong window for scrolling
> when there are more than 2 windows on the frame.
>
> Maybe like there is a variable other-window-scroll-buffer,
> it would be nice to add a new user option
> other-window-for-scrolling-function that will return
> a window for scrolling.

+1. I often have multiple frames with only one window, so it would be
useful to customize this proposed variable to a function that returns a
window on a different frame if there is only one window on the current
frame.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 17:48:03 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 19:47:36 +0200
> Maybe like there is a variable other-window-scroll-buffer,
> it would be nice to add a new user option
> other-window-for-scrolling-function that will return
> a window for scrolling.  It could provide a choise list that
> includes a function that returns the most-recently-used window.

Maybe a variable 'other-window-scroll-window' whose value could be a
function to get that window.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 18:02:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 20:58:22 +0300
>> Often scroll-other-window uses a wrong window for scrolling
>> when there are more than 2 windows on the frame.
>
> Which one is the "right" window?

The right window would be most-recently-used window like can be
customized in e.g. compare-windows-get-window-function.

> And can you show a recipe for the issue?

A recipe is to create 3 windows and to try scrolling
a window that is not next-window.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 18:02:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: <jakanakaevangeli <at> chiru.no>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 20:59:12 +0300
> +1. I often have multiple frames with only one window, so it would be
> useful to customize this proposed variable to a function that returns a
> window on a different frame if there is only one window on the current
> frame.

This would be a useful option for the new variable.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 18:02:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 21:00:23 +0300
>> Maybe like there is a variable other-window-scroll-buffer,
>> it would be nice to add a new user option
>> other-window-for-scrolling-function that will return
>> a window for scrolling.  It could provide a choise list that
>> includes a function that returns the most-recently-used window.
>
> Maybe a variable 'other-window-scroll-window' whose value could be a
> function to get that window.

The word "window" appears twice in the name,
but maybe this is still the best possible name.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 18:05:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: <jakanakaevangeli <at> chiru.no>
Cc: 51210 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 21:04:01 +0300
> From: <jakanakaevangeli <at> chiru.no>
> Date: Thu, 14 Oct 2021 19:37:20 +0200
> 
> Juri Linkov <juri <at> linkov.net> writes:
> 
> > Often scroll-other-window uses a wrong window for scrolling
> > when there are more than 2 windows on the frame.
> >
> > Maybe like there is a variable other-window-scroll-buffer,
> > it would be nice to add a new user option
> > other-window-for-scrolling-function that will return
> > a window for scrolling.
> 
> +1. I often have multiple frames with only one window, so it would be
> useful to customize this proposed variable to a function that returns a
> window on a different frame if there is only one window on the current
> frame.

Wouldn't it be easier to add a new command scroll-other-frame?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 18:07:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 21:06:25 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: 51210 <at> debbugs.gnu.org
> Date: Thu, 14 Oct 2021 20:58:22 +0300
> 
> >> Often scroll-other-window uses a wrong window for scrolling
> >> when there are more than 2 windows on the frame.
> >
> > Which one is the "right" window?
> 
> The right window would be most-recently-used window like can be
> customized in e.g. compare-windows-get-window-function.

For me, it's always the next-window.  Which explains why you aren't
satisfied: you expect something else.  So why not have a new command,
scroll-mru-window?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 18:30:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 21:25:24 +0300
>> The right window would be most-recently-used window like can be
>> customized in e.g. compare-windows-get-window-function.
>
> For me, it's always the next-window.  Which explains why you aren't
> satisfied: you expect something else.  So why not have a new command,
> scroll-mru-window?

and

> Wouldn't it be easier to add a new command scroll-other-frame?

It's much easier to customize one variable to the needed function
that to create a dozen of commands and rebind them to the same keys
because there are many commands that will use the new variable:

scroll-other-window bound to M-<next>, C-M-v
scroll-other-window-down bound to M-<prior>, C-M-S-v
recenter-other-window bound to C-M-S-l
beginning-of-buffer-other-window bound to M-<begin>, M-<home>
end-of-buffer-other-window bound to M-<end>
...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 18:38:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 21:37:27 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: 51210 <at> debbugs.gnu.org
> Date: Thu, 14 Oct 2021 21:25:24 +0300
> 
> >> The right window would be most-recently-used window like can be
> >> customized in e.g. compare-windows-get-window-function.
> >
> > For me, it's always the next-window.  Which explains why you aren't
> > satisfied: you expect something else.  So why not have a new command,
> > scroll-mru-window?
> 
> and
> 
> > Wouldn't it be easier to add a new command scroll-other-frame?
> 
> It's much easier to customize one variable to the needed function
> that to create a dozen of commands and rebind them to the same keys
> because there are many commands that will use the new variable:
> 
> scroll-other-window bound to M-<next>, C-M-v
> scroll-other-window-down bound to M-<prior>, C-M-S-v
> recenter-other-window bound to C-M-S-l
> beginning-of-buffer-other-window bound to M-<begin>, M-<home>
> end-of-buffer-other-window bound to M-<end>

The advantage of having separate commands is that users can then have
several behaviors at once.  By contrast, a single customizable
variable can provide only one of the possible behaviors.  Not everyone
wants only ever scroll the most-recently-used window or the single
window on another frame, some of the users might want sometimes to
scroll next-window, sometimes the most-recently-used one, and
sometimes the one on the other frame.

And it isn't like it would be hard to write those few commands, it
should be almost trivial.  Not harder than writing those functions to
return the window you want, anyway.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 18:48:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 21:45:08 +0300
> The advantage of having separate commands is that users can then have
> several behaviors at once.  By contrast, a single customizable
> variable can provide only one of the possible behaviors.  Not everyone
> wants only ever scroll the most-recently-used window or the single
> window on another frame, some of the users might want sometimes to
> scroll next-window, sometimes the most-recently-used one, and
> sometimes the one on the other frame.
>
> And it isn't like it would be hard to write those few commands, it
> should be almost trivial.  Not harder than writing those functions to
> return the window you want, anyway.

If you want to write such commands, still it would be much easier
to implement them using the new variable, e.g.

(defun scroll-mru-window ()
  (interactive)
  (let ((other-window-scroll-window 'get-mru-window)
    (scroll-other-window))))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 14 Oct 2021 18:53:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 14 Oct 2021 21:52:43 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: 51210 <at> debbugs.gnu.org
> Date: Thu, 14 Oct 2021 21:45:08 +0300
> 
> > The advantage of having separate commands is that users can then have
> > several behaviors at once.  By contrast, a single customizable
> > variable can provide only one of the possible behaviors.  Not everyone
> > wants only ever scroll the most-recently-used window or the single
> > window on another frame, some of the users might want sometimes to
> > scroll next-window, sometimes the most-recently-used one, and
> > sometimes the one on the other frame.
> >
> > And it isn't like it would be hard to write those few commands, it
> > should be almost trivial.  Not harder than writing those functions to
> > return the window you want, anyway.
> 
> If you want to write such commands, still it would be much easier
> to implement them using the new variable, e.g.
> 
> (defun scroll-mru-window ()
>   (interactive)
>   (let ((other-window-scroll-window 'get-mru-window)
>     (scroll-other-window))))

Of course!  All I'm saying is let's not limit ourselves to just the
variable, as it will satisfy only some users, those who always want
only one kind of behavior regarding scrolling other windows.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Wed, 29 Dec 2021 17:33:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Wed, 29 Dec 2021 19:31:13 +0200
[Message part 1 (text/plain, inline)]
>> Maybe like there is a variable other-window-scroll-buffer,
>> it would be nice to add a new user option
>> other-window-for-scrolling-function that will return
>> a window for scrolling.  It could provide a choise list that
>> includes a function that returns the most-recently-used window.
>
> Maybe a variable 'other-window-scroll-window' whose value could be a
> function to get that window.

Since there is already the word "window" in the function name,
maybe better would be 'other-window-scroll-default' that hints
that it overrides the default that is the next window:

[other-window-scroll-default.patch (text/x-diff, inline)]
diff --git a/src/window.c b/src/window.c
index e801ff821f..d06a706e58 100644
--- a/src/window.c
+++ b/src/window.c
@@ -6307,10 +6307,12 @@ DEFUN ("other-window-for-scrolling", Fother_window_for_scrolling, Sother_window_
       if (NILP (window))
 	window = display_buffer (Vother_window_scroll_buffer, Qt, Qnil);
     }
+  else if (FUNCTIONP (Vother_window_scroll_default))
+    /* Nothing specified; try to get a window from the function.  */
+    window = call0 (Vother_window_scroll_default);
   else
     {
-      /* Nothing specified; look for a neighboring window on the same
-	 frame.  */
+      /* Otherwise, look for a neighboring window on the same frame.  */
       window = Fnext_window (selected_window, Qlambda, Qnil);
 
       if (EQ (window, selected_window))
@@ -8268,6 +8270,15 @@ syms_of_window (void)
 	       doc: /* If this is a live buffer, \\[scroll-other-window] should scroll its window.  */);
   Vother_window_scroll_buffer = Qnil;
 
+  DEFVAR_LISP ("other-window-scroll-default", Vother_window_scroll_default,
+	       doc: /* Function that provides the window to scroll by \\[scroll-other-window].
+The function `other-window-for-scrolling' first tries to use
+`minibuffer-scroll-window' and `other-window-scroll-buffer'.
+But when both are nil, then by default it uses a neighboring window.
+This variable is intended to provide another default instead of
+a neighboring window.  */);
+  Vother_window_scroll_default = Qnil;
+
   DEFVAR_BOOL ("auto-window-vscroll", auto_window_vscroll_p,
 	       doc: /* Non-nil means to automatically adjust `window-vscroll' to view tall lines.  */);
   auto_window_vscroll_p = true;

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Fri, 31 Dec 2021 09:13:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Fri, 31 Dec 2021 10:11:53 +0100
>> Maybe a variable 'other-window-scroll-window' whose value could be a
>> function to get that window.
>
> Since there is already the word "window" in the function name,
> maybe better would be 'other-window-scroll-default' that hints
> that it overrides the default that is the next window:

Since we already have 'other-window-scroll-buffer' this might be
confusing.  And shouldn't a window, if specified, override a specified
buffer?  BTW I think we should move 'other-window-for-scrolling' to
window.el - all it does is call Lisp primitives.  And turn
scroll_command into 'Fscroll_command' (or, better 'Fscroll_window') so
things like 'scroll-down' (or, better 'scroll-window-down') and
'scroll-other-window-down' could end up in window.el too.  But maybe I'm
missing some important detail.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Tue, 04 Jan 2022 08:46:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Tue, 04 Jan 2022 10:38:41 +0200
>>> Maybe a variable 'other-window-scroll-window' whose value could be a
>>> function to get that window.
>>
>> Since there is already the word "window" in the function name,
>> maybe better would be 'other-window-scroll-default' that hints
>> that it overrides the default that is the next window:
>
> Since we already have 'other-window-scroll-buffer' this might be
> confusing.

It's named intentionally to be similar with 'other-window-scroll-buffer'.

> And shouldn't a window, if specified, override a specified buffer?

Its purpose is to override only the part that hard-codes 'next-window'.

> BTW I think we should move 'other-window-for-scrolling' to
> window.el - all it does is call Lisp primitives.  And turn
> scroll_command into 'Fscroll_command' (or, better 'Fscroll_window') so
> things like 'scroll-down' (or, better 'scroll-window-down') and
> 'scroll-other-window-down' could end up in window.el too.  But maybe I'm
> missing some important detail.

I agree it would be nice to move scrolling commands to Lisp.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Tue, 04 Jan 2022 10:28:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Tue, 4 Jan 2022 11:27:21 +0100
>> And shouldn't a window, if specified, override a specified buffer?
>
> Its purpose is to override only the part that hard-codes 'next-window'.

How about a variable 'other-window-to-scroll-function' whose default
value is 'next-window'?

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Tue, 04 Jan 2022 13:14:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Tue, 04 Jan 2022 15:13:37 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Date: Tue, 04 Jan 2022 10:38:41 +0200
> Cc: 51210 <at> debbugs.gnu.org
> 
> I agree it would be nice to move scrolling commands to Lisp.

How do you envision being able to do that?  The implementation makes
screen layout decisions by simulating redisplay, and that is not
possible in Lisp, at least not without exposing new primitives (which
I personally would object to, for more than one reason).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Tue, 04 Jan 2022 17:52:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Tue, 04 Jan 2022 19:37:54 +0200
>>> And shouldn't a window, if specified, override a specified buffer?
>>
>> Its purpose is to override only the part that hard-codes 'next-window'.
>
> How about a variable 'other-window-to-scroll-function' whose default
> value is 'next-window'?

The default behavior is more complex than just 'next-window':

  else if (FUNCTIONP (Vother_window_scroll_default))
    /* Nothing specified; try to get a window from the function.  */
    window = call0 (Vother_window_scroll_default);
  else
    {
      /* Otherwise, look for a neighboring window on the same frame.  */
      window = Fnext_window (selected_window, Qlambda, Qnil);

      if (EQ (window, selected_window))
	/* That didn't get us anywhere; look for a window on another
           visible frame on the current terminal.  */
        window = Fnext_window (window, Qlambda, Qvisible);
    }




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Tue, 04 Jan 2022 17:52:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Tue, 04 Jan 2022 19:40:52 +0200
>>> BTW I think we should move 'other-window-for-scrolling' to
>>> window.el - all it does is call Lisp primitives.  And turn
>>> scroll_command into 'Fscroll_command' (or, better 'Fscroll_window') so
>>> things like 'scroll-down' (or, better 'scroll-window-down') and
>>> 'scroll-other-window-down' could end up in window.el too.  But maybe I'm
>>> missing some important detail.
>>
>> I agree it would be nice to move scrolling commands to Lisp.
>
> How do you envision being able to do that?  The implementation makes
> screen layout decisions by simulating redisplay, and that is not
> possible in Lisp, at least not without exposing new primitives (which
> I personally would object to, for more than one reason).

At least, 'other-window-for-scrolling' could be moved to window.el.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Tue, 11 Jan 2022 17:31:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Tue, 11 Jan 2022 19:29:37 +0200
close 51210 29.0.50
thanks

>>> Its purpose is to override only the part that hard-codes 'next-window'.
>>
>> How about a variable 'other-window-to-scroll-function' whose default
>> value is 'next-window'?
>
> The default behavior is more complex than just 'next-window':
>
>   else if (FUNCTIONP (Vother_window_scroll_default))
>     /* Nothing specified; try to get a window from the function.  */
>     window = call0 (Vother_window_scroll_default);
>   else
>     {
>       /* Otherwise, look for a neighboring window on the same frame.  */
>       window = Fnext_window (selected_window, Qlambda, Qnil);
>
>       if (EQ (window, selected_window))
> 	/* That didn't get us anywhere; look for a window on another
>            visible frame on the current terminal.  */
>         window = Fnext_window (window, Qlambda, Qvisible);
>     }

So I pushed this.  If you have better suggestions, this could be reopened.




bug marked as fixed in version 29.0.50, send any further explanations to 51210 <at> debbugs.gnu.org and Juri Linkov <juri <at> linkov.net> Request was from Juri Linkov <juri <at> linkov.net> to control <at> debbugs.gnu.org. (Tue, 11 Jan 2022 17:31:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Tue, 11 Jan 2022 18:42:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Tue, 11 Jan 2022 20:40:34 +0200
BTW, this doc fix is for the release branch, this text is no more valid
from Emacs 27:

diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
index 56b4bc5183..bbf8988e5c 100644
--- a/doc/lispref/windows.texi
+++ b/doc/lispref/windows.texi
@@ -5281,13 +5281,6 @@ Textual Scrolling
 minibuffer is selected, it takes precedence over
 @code{other-window-scroll-buffer}.  @xref{Definition of
 minibuffer-scroll-window}.
-
-When the minibuffer is active, it is the next window if the selected
-window is the one at the bottom right corner.  In this case,
-@code{scroll-other-window} attempts to scroll the minibuffer.  If the
-minibuffer contains just one line, it has nowhere to scroll to, so the
-line reappears after the echo area momentarily displays the message
-@samp{End of buffer}.
 @end deffn
 
 @deffn Command scroll-other-window-down &optional count
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Tue, 11 Jan 2022 19:03:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Tue, 11 Jan 2022 20:58:10 +0200
There are also nice commands: M-<home> (beginning-of-buffer-other-window)
and M-<end> (end-of-buffer-other-window), but for no reason they recenter
the other window after moving to the beginning/end.

It would be better to remove this disservice:

diff --git a/lisp/window.el b/lisp/window.el
index 582600e1c6..45c6b36b21 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -10105,9 +10105,7 @@ beginning-of-buffer-other-window
   (with-selected-window (other-window-for-scrolling)
     ;; Set point and mark in that window's buffer.
     (with-no-warnings
-      (beginning-of-buffer arg))
-    ;; Set point accordingly.
-    (recenter '(t))))
+      (beginning-of-buffer arg))))
 
 (defun end-of-buffer-other-window (arg)
   "Move point to the end of the buffer in the other window.
@@ -10117,8 +10115,7 @@ end-of-buffer-other-window
   ;; See beginning-of-buffer-other-window for comments.
   (with-selected-window (other-window-for-scrolling)
     (with-no-warnings
-      (end-of-buffer arg))
-    (recenter '(t))))
+      (end-of-buffer arg))))
 
 (defvar mouse-autoselect-window-timer nil
   "Timer used by delayed window autoselection.")
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Tue, 11 Jan 2022 20:09:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Tue, 11 Jan 2022 22:08:01 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Date: Tue, 11 Jan 2022 20:58:10 +0200
> Cc: 51210 <at> debbugs.gnu.org
> 
> There are also nice commands: M-<home> (beginning-of-buffer-other-window)
> and M-<end> (end-of-buffer-other-window), but for no reason they recenter
> the other window after moving to the beginning/end.
> 
> It would be better to remove this disservice:

This is age-old behavior.  Why change it because you happen to dislike
it?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Wed, 12 Jan 2022 18:06:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Wed, 12 Jan 2022 20:04:32 +0200
>> There are also nice commands: M-<home> (beginning-of-buffer-other-window)
>> and M-<end> (end-of-buffer-other-window), but for no reason they recenter
>> the other window after moving to the beginning/end.
>> 
>> It would be better to remove this disservice:
>
> This is age-old behavior.  Why change it because you happen to dislike
> it?

The problem is that with its current implementation, it's unusable:
when the window height is 75 lines, then typing M-<end> leaves
half-screen empty.

But fortunately this can be fixed since Emacs 28 introduced a new key
C-M-S-l to recenter the other window, so it's now easy to type it
when the user needs to recenter the other window.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Wed, 12 Jan 2022 19:30:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Wed, 12 Jan 2022 21:29:33 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rudalics <at> gmx.at,  51210 <at> debbugs.gnu.org
> Date: Wed, 12 Jan 2022 20:04:32 +0200
> 
> >> There are also nice commands: M-<home> (beginning-of-buffer-other-window)
> >> and M-<end> (end-of-buffer-other-window), but for no reason they recenter
> >> the other window after moving to the beginning/end.
> >> 
> >> It would be better to remove this disservice:
> >
> > This is age-old behavior.  Why change it because you happen to dislike
> > it?
> 
> The problem is that with its current implementation, it's unusable:
> when the window height is 75 lines, then typing M-<end> leaves
> half-screen empty.

If you start typing at the end of the buffer, the half-empty window
will immediately make sense.

Are you using scroll-conservatively, perhaps?  If so, I can understand
why you don't like this behavior.  But that's your subjective opinion,
and I see no reason to change this by default.

> But fortunately this can be fixed since Emacs 28 introduced a new key
> C-M-S-l to recenter the other window, so it's now easy to type it
> when the user needs to recenter the other window.

Great.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Wed, 12 Jan 2022 19:46:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Wed, 12 Jan 2022 21:45:00 +0200
>> >> There are also nice commands: M-<home> (beginning-of-buffer-other-window)
>> >> and M-<end> (end-of-buffer-other-window), but for no reason they recenter
>> >> the other window after moving to the beginning/end.
>> >> 
>> >> It would be better to remove this disservice:
>> >
>> > This is age-old behavior.  Why change it because you happen to dislike
>> > it?
>> 
>> The problem is that with its current implementation, it's unusable:
>> when the window height is 75 lines, then typing M-<end> leaves
>> half-screen empty.
>
> If you start typing at the end of the buffer, the half-empty window
> will immediately make sense.

You can't start typing because it's in another window.

> Are you using scroll-conservatively, perhaps?  If so, I can understand
> why you don't like this behavior.  But that's your subjective opinion,
> and I see no reason to change this by default.

This problem is reproducible in emacs -Q:
visit e.g. TODO with 'C-h C-t', split windows with 'C-x 3',
and type 'M-<end>'.  Then another window is recentered.

>> But fortunately this can be fixed since Emacs 28 introduced a new key
>> C-M-S-l to recenter the other window, so it's now easy to type it
>> when the user needs to recenter the other window.
>
> Great.

So everyone who wants to recenter, can type: 'M-<end> M-C-S-l'.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Wed, 12 Jan 2022 19:52:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Wed, 12 Jan 2022 21:51:41 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rudalics <at> gmx.at,  51210 <at> debbugs.gnu.org
> Date: Wed, 12 Jan 2022 21:45:00 +0200
> 
> >> > This is age-old behavior.  Why change it because you happen to dislike
> >> > it?
> >> 
> >> The problem is that with its current implementation, it's unusable:
> >> when the window height is 75 lines, then typing M-<end> leaves
> >> half-screen empty.
> >
> > If you start typing at the end of the buffer, the half-empty window
> > will immediately make sense.
> 
> You can't start typing because it's in another window.

Fortunately, Emacs has this "C-x o" command that fixes that small
problem.

> > Are you using scroll-conservatively, perhaps?  If so, I can understand
> > why you don't like this behavior.  But that's your subjective opinion,
> > and I see no reason to change this by default.
> 
> This problem is reproducible in emacs -Q:

I think you misunderstood me.  I was trying to explain to myself why
you don't like the default behavior.

> >> But fortunately this can be fixed since Emacs 28 introduced a new key
> >> C-M-S-l to recenter the other window, so it's now easy to type it
> >> when the user needs to recenter the other window.
> >
> > Great.
> 
> So everyone who wants to recenter, can type: 'M-<end> M-C-S-l'.

I object to changing this behavior by default.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Wed, 12 Jan 2022 20:02:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Wed, 12 Jan 2022 21:59:41 +0200
>> >> The problem is that with its current implementation, it's unusable:
>> >> when the window height is 75 lines, then typing M-<end> leaves
>> >> half-screen empty.
>> >
>> > If you start typing at the end of the buffer, the half-empty window
>> > will immediately make sense.
>> 
>> You can't start typing because it's in another window.
>
> Fortunately, Emacs has this "C-x o" command that fixes that small
> problem.

But "C-x o C-<end>" doesn't recenter after moving to the end of the buffer.

>> >> But fortunately this can be fixed since Emacs 28 introduced a new key
>> >> C-M-S-l to recenter the other window, so it's now easy to type it
>> >> when the user needs to recenter the other window.
>> >
>> > Great.
>> 
>> So everyone who wants to recenter, can type: 'M-<end> M-C-S-l'.
>
> I object to changing this behavior by default.

Then how this problem can be fixed?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Wed, 12 Jan 2022 20:42:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Wed, 12 Jan 2022 22:41:23 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rudalics <at> gmx.at,  51210 <at> debbugs.gnu.org
> Date: Wed, 12 Jan 2022 21:59:41 +0200
> 
> > I object to changing this behavior by default.
> 
> Then how this problem can be fixed?

If you must change it, please introduce a user option,l by default
off.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Mon, 17 Jan 2022 08:48:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Mon, 17 Jan 2022 10:44:36 +0200
> If you must change it, please introduce a user option, by default
> off.

An option could be added indeed, but wasn't 'recenter' intended
only to refresh the screen, not to recenter?

'beginning-of-buffer-other-window' has such line at the end:

  (recenter '(t))

Clearly it makes no sense to recenter at the beginning of the buffer.
So the value '(t)' was intended only to refresh the screen?
Then the same line in 'end-of-buffer-other-window'
should only refresh the screen, not recenter.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Mon, 17 Jan 2022 12:34:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Mon, 17 Jan 2022 14:33:21 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rudalics <at> gmx.at,  51210 <at> debbugs.gnu.org
> Date: Mon, 17 Jan 2022 10:44:36 +0200
> 
> > If you must change it, please introduce a user option, by default
> > off.
> 
> An option could be added indeed, but wasn't 'recenter' intended
> only to refresh the screen, not to recenter?

No, it's the other way around: the command was meant to recenter and
_also_ to refresh the screen.

> 'beginning-of-buffer-other-window' has such line at the end:
> 
>   (recenter '(t))
> 
> Clearly it makes no sense to recenter at the beginning of the buffer.
> So the value '(t)' was intended only to refresh the screen?
> Then the same line in 'end-of-buffer-other-window'
> should only refresh the screen, not recenter.

I'm not sure I understand how all of this is relevant.  Please
elaborate.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Mon, 24 Jan 2022 19:44:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Mon, 24 Jan 2022 21:42:15 +0200
>> 'beginning-of-buffer-other-window' has such line at the end:
>> 
>>   (recenter '(t))
>> 
>> Clearly it makes no sense to recenter at the beginning of the buffer.
>> So the value '(t)' was intended only to refresh the screen?
>> Then the same line in 'end-of-buffer-other-window'
>> should only refresh the screen, not recenter.
>
> I'm not sure I understand how all of this is relevant.  Please
> elaborate.

Currently the implementation of beginning-of-buffer-other-window
is this:

(defun beginning-of-buffer-other-window (arg)
  (with-selected-window (other-window-for-scrolling)
    ;; Set point and mark in that window's buffer.
    (with-no-warnings
      (beginning-of-buffer arg))
    ;; Set point accordingly.
    (recenter '(t))))

It's not clear what does the last comment mean.
'recenter' should set point accordingly to what?
And what does (recenter '(t)) do at the beginning of the buffer?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Mon, 24 Jan 2022 19:54:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Mon, 24 Jan 2022 21:53:04 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rudalics <at> gmx.at,  51210 <at> debbugs.gnu.org
> Date: Mon, 24 Jan 2022 21:42:15 +0200
> 
> >> 'beginning-of-buffer-other-window' has such line at the end:
> >> 
> >>   (recenter '(t))
> >> 
> >> Clearly it makes no sense to recenter at the beginning of the buffer.
> >> So the value '(t)' was intended only to refresh the screen?
> >> Then the same line in 'end-of-buffer-other-window'
> >> should only refresh the screen, not recenter.
> >
> > I'm not sure I understand how all of this is relevant.  Please
> > elaborate.
> 
> Currently the implementation of beginning-of-buffer-other-window
> is this:
> 
> (defun beginning-of-buffer-other-window (arg)
>   (with-selected-window (other-window-for-scrolling)
>     ;; Set point and mark in that window's buffer.
>     (with-no-warnings
>       (beginning-of-buffer arg))
>     ;; Set point accordingly.
>     (recenter '(t))))
> 
> It's not clear what does the last comment mean.
> 'recenter' should set point accordingly to what?
> And what does (recenter '(t)) do at the beginning of the buffer?

It isn't beginning of buffer, it's where (beginning-of-buffer arg)
puts point when ARG is non-nil.  See the doc string of
beginning-of-buffer.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Thu, 27 Jan 2022 17:50:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Thu, 27 Jan 2022 19:40:51 +0200
>> (defun beginning-of-buffer-other-window (arg)
>>   (with-selected-window (other-window-for-scrolling)
>>     ;; Set point and mark in that window's buffer.
>>     (with-no-warnings
>>       (beginning-of-buffer arg))
>>     ;; Set point accordingly.
>>     (recenter '(t))))
>> 
>> It's not clear what does the last comment mean.
>> 'recenter' should set point accordingly to what?
>> And what does (recenter '(t)) do at the beginning of the buffer?
>
> It isn't beginning of buffer, it's where (beginning-of-buffer arg)
> puts point when ARG is non-nil.  See the doc string of
> beginning-of-buffer.

Sorry, I didn't notice it takes an argument.  Then it's strange
that it doesnt't recenter according to recenter-top-bottom that
uses recenter-positions.  So two most useful behaviors
(recenter-top-bottom for beginning-of-buffer-other-window and
no recentering for end-of-buffer-other-window) are not supported.
Since the default can't be changed, maybe a new optional argument
could define whether to use recenter-top-bottom, or no recenter at all.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Fri, 28 Jan 2022 13:46:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Fri, 28 Jan 2022 15:45:13 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Cc: rudalics <at> gmx.at,  51210 <at> debbugs.gnu.org
> Date: Thu, 27 Jan 2022 19:40:51 +0200
> 
> > It isn't beginning of buffer, it's where (beginning-of-buffer arg)
> > puts point when ARG is non-nil.  See the doc string of
> > beginning-of-buffer.
> 
> Sorry, I didn't notice it takes an argument.  Then it's strange
> that it doesnt't recenter according to recenter-top-bottom that
> uses recenter-positions.  So two most useful behaviors
> (recenter-top-bottom for beginning-of-buffer-other-window and
> no recentering for end-of-buffer-other-window) are not supported.
> Since the default can't be changed, maybe a new optional argument
> could define whether to use recenter-top-bottom, or no recenter at all.

I don't mind having a new option, but is recenter-positions really
relevant to beginning-of-buffer-other-window? why would users want to
have beginning-of-buffer-other-window recenter in non-default ways,
just because they customized recenter-positions?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51210; Package emacs. (Sat, 29 Jan 2022 18:55:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 51210 <at> debbugs.gnu.org
Subject: Re: bug#51210: Customizable other-window-for-scrolling
Date: Sat, 29 Jan 2022 20:53:54 +0200
>> Sorry, I didn't notice it takes an argument.  Then it's strange
>> that it doesnt't recenter according to recenter-top-bottom that
>> uses recenter-positions.  So two most useful behaviors
>> (recenter-top-bottom for beginning-of-buffer-other-window and
>> no recentering for end-of-buffer-other-window) are not supported.
>> Since the default can't be changed, maybe a new optional argument
>> could define whether to use recenter-top-bottom, or no recenter at all.
>
> I don't mind having a new option, but is recenter-positions really
> relevant to beginning-of-buffer-other-window? why would users want to
> have beginning-of-buffer-other-window recenter in non-default ways,
> just because they customized recenter-positions?

beginning/end-of-buffer-other-window looked like abandoned commands,
so I thought they might need more work.  But since they will keep
the current behavior, it's much easier to customize them with advice:

  (advice-add 'beginning-of-buffer-other-window :after
              (lambda (&rest _args)
                (with-selected-window (other-window-for-scrolling)
                  (recenter-top-bottom))))

  (advice-add 'end-of-buffer-other-window :after
              (lambda (&rest _args)
                (with-selected-window (other-window-for-scrolling)
                  (recenter -1))))

Anyway, the objective of this request was completed, so it's already closed.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 27 Feb 2022 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 30 days ago.

Previous Next


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