GNU bug report logs - #38502
27.0.50; minibuffer-scroll-other-window with multiple frames

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: nvp <noah.v.peart <at> gmail.com>, 38502 <at> debbugs.gnu.org
Subject: bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames
Date: Mon, 9 Dec 2019 21:07:03 -0800 (PST)

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

Previous Next

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