bug#51210: Customizable other-window-for-scrolling

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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.

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@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?

bug#51210: Customizable other-window-for-scrolling

[jakanakaevangeli]

Juri Linkov <juri@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.

bug#51210: Customizable other-window-for-scrolling

[martin rudalics]

 > 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

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: <jakanakaevangeli@chiru.no>
> Date: Thu, 14 Oct 2021 19:37:20 +0200
> 
> Juri Linkov <juri@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?

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 51210@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?

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 51210@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.

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 51210@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.

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: other-window-scroll-default.patch --]
[-- Type: text/x-diff, Size: 1650 bytes --]

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;

bug#51210: Customizable other-window-for-scrolling

[martin rudalics]

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

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[martin rudalics]

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

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 04 Jan 2022 10:38:41 +0200
> Cc: 51210@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).

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

>>> 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);
    }

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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))))
 \f
 (defvar mouse-autoselect-window-timer nil
   "Timer used by delayed window autoselection.")
-- 

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 11 Jan 2022 20:58:10 +0200
> Cc: 51210@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?

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  51210@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.

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  51210@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.

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  51210@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.

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  51210@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.

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

>> '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?

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  51210@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.

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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

bug#51210: Customizable other-window-for-scrolling

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  51210@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?

bug#51210: Customizable other-window-for-scrolling

[Juri Linkov]

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