RE: Suggestions for the temporary windows used from the minibuffer

[Drew Adams]

On a slightly related subject -

Commands scroll-other-window and scroll-other-window-down manipulate the
"other" window, if it exists. If it doesn't, they do nothing. That makes
sense for the commands, but not for the keys they are bound to.

Keys are limited, and handy pairs of keys like (<M-next>, <M-prior>) and
(C-M-v, C-M-S-v) are even more limited. It's a shame to bind such keys to
commands that do nothing when there is no "other" window. Especially for
people who use non-nil pop-up-frames. (Yes, of course people can rebind the
keys, but...)

What about:

For keys that are bound to commands that manipulate the "other" window (not
commands that open another window, but commands that use an existing one),
bind them instead to commands that do the same thing when there is another
window, but let the user do something else, otherwise? For instance, instead
of binding C-M-v and M-next to scroll-other-window, bind them to something
like scroll-other-window-or-*:

(defun scroll-other-window-or-* (&optional arg)
  "If other window, scroll-other-window; else, s-o-w-alternate."
  (interactive "p")
  (if (or (not (one-window-p)) other-window-scroll-buffer)
      (scroll-other-window arg)
    (funcall 's-o-w-alternate arg)))

Then, users and libraries can do (setq s-o-w-alternate-fn 'foo-command).
They don't have to rebind the various keys to foo-command, and they don't
lose the other-window functionality whenever it is truly available.

I know this smells like a crazy, ugly hack, but perhaps it could be useful?

Of course, instead of creating a scroll-other-window-or-* command, the
original command could be changed in the same way: instead of doing nothing
when no other window, run another command (~hook).

Another, weirder possibility would be to treat the existence of an open
other window as a minor mode, and bind the scroll-other-* commands only in
that mode.