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.