bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames

[Drew Adams]

> >>> Is S-TAB referring to <backtab>?  That is unbound (default) in this
> >>> context for me.
> >>
> >> Indeed there is no counterpart to TAB for scrolling the completion
> >> window in the opposite direction.  Maybe <backtab> and S-TAB should
> >> do this.
> >
> > FWIW:
> >
> > I'd suggest that both TAB and S-TAB (<backtab>) be left
> > alone, as they are natural for completion in some way
> > (e.g. cycling among candidates).
> 
> This is exactly what I meant - TAB cycles completions forward,
> so S-TAB could cycle backward.

Based on the Subject line and your speaking of
"scrolling the completion window" I thought you
meant scrolling the completion window. ;-)

By "cycling among candidates" I meant cycling
among candidates.

In vanilla Emacs I guess that means only what
`completion-cycle-threshold' offers.  (With
other completion approaches it can mean other
ways of cycling among candidates.)

Anyway, just one opinion against binding S-TAB.
I'm in favor of leaving it open, for users and
libraries to bind during completion.

(Yes, they can do that even if Emacs gives it a
default binding.  But I'm not a fan of Emacs
taking up all the oxygen wrt key bindings, as
seems to be more and more the case.)

As I say, just one opinion.