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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38502 in the body.
You can then email your comments to 38502 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: noah <noah.v.peart <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; minibuffer-scroll-other-window with multiple frames
Date: Thu, 05 Dec 2019 14:03:18 -0500

I think this is new within the last week or so.
When a completion frame pops up while using the minibuffer,
normally the minibuffer-scroll-other-window(-down) functions
scroll the completion window.  However, now when emacs is split
into two horizontal frames, these functions ignore the
completion buffer and scroll the others.

To reproduce from emacs -Q:

    C-x 3
    M-: (mak
    TAB for completions
    C-M-v



In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2019-12-04 built on noah-M51AC
Repository revision: 23053770449ba1af24961a11d803ae5e948130b6
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Ubuntu 18.04.3 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit [2 times]
Sole completion
Complete, but not unique
Making completion list... [2 times]
Sole completion
Loading /home/noah/.gnus...done
Type C-x 1 to delete the help window.

Configured using:
 'configure --prefix=/usr/local --with-modules --with-xwidgets'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr cl-extra help-fns radix-tree help-mode emacsbug
message rmc puny dired dired-loaddefs format-spec rfc822 mml easymenu
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search time-date subr-x seq byte-opt gv
bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal move-toolbar
gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 47776 16104)
 (symbols 48 6212 1)
 (strings 32 16512 1685)
 (string-bytes 1 533391)
 (vectors 16 10517)
 (vector-slots 8 134061 14424)
 (floats 8 31 34)
 (intervals 56 225 0)
 (buffers 1000 13))

Message #8 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: noah <noah.v.peart <at> gmail.com>, Juri Linkov <juri <at> linkov.net>
Cc: 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50;
 minibuffer-scroll-other-window with multiple frames
Date: Thu, 05 Dec 2019 21:16:52 +0200

> From: noah <noah.v.peart <at> gmail.com>
> Date: Thu, 05 Dec 2019 14:03:18 -0500
> 
> I think this is new within the last week or so.
> When a completion frame pops up while using the minibuffer,
> normally the minibuffer-scroll-other-window(-down) functions
> scroll the completion window.  However, now when emacs is split
> into two horizontal frames, these functions ignore the
> completion buffer and scroll the others.
> 
> To reproduce from emacs -Q:
> 
>     C-x 3
>     M-: (mak
>     TAB for completions
>     C-M-v

Probably related to recent message/minibuffer-message changes.

Message #11 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: nvp <noah.v.peart <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38502 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#38502: 27.0.50;
 minibuffer-scroll-other-window with multiple frames
Date: Thu, 5 Dec 2019 16:59:13 -0500

[Message part 1 (text/plain, inline)]

The snazzy new completion coloring is nice though!

On Thu, Dec 5, 2019 at 2:17 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: noah <noah.v.peart <at> gmail.com>
> > Date: Thu, 05 Dec 2019 14:03:18 -0500
> >
> > I think this is new within the last week or so.
> > When a completion frame pops up while using the minibuffer,
> > normally the minibuffer-scroll-other-window(-down) functions
> > scroll the completion window.  However, now when emacs is split
> > into two horizontal frames, these functions ignore the
> > completion buffer and scroll the others.
> >
> > To reproduce from emacs -Q:
> >
> >     C-x 3
> >     M-: (mak
> >     TAB for completions
> >     C-M-v
>
> Probably related to recent message/minibuffer-message changes.
>

[Message part 2 (text/html, inline)]

Message #14 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: noah <noah.v.peart <at> gmail.com>
Cc: 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50; minibuffer-scroll-other-window with
 multiple frames
Date: Fri, 06 Dec 2019 02:02:53 +0200

> I think this is new within the last week or so.
> When a completion frame pops up while using the minibuffer,
> normally the minibuffer-scroll-other-window(-down) functions
> scroll the completion window.  However, now when emacs is split
> into two horizontal frames, these functions ignore the
> completion buffer and scroll the others.
>
> To reproduce from emacs -Q:
>
>     C-x 3
>     M-: (mak
>     TAB for completions
>     C-M-v

TAB and S-TAB should scroll the the completion buffer.  But what about C-M-v?
Is it documented somewhere what buffer it's intended to scroll?
I can find only this text in (info "(emacs) Minibuffer Edit"):

     The ‘C-M-v’ command in the minibuffer scrolls the help text from
  commands that display help text of any sort in another window.  You can
  also scroll the help text with ‘M-<PageUp>’ and ‘M-<PageDown>’ (or,
  equivalently, ‘M-<prior>’ and ‘M-<next>’).  This is especially useful
  with long lists of possible completions.

Does this mean the help text is the same as the completion buffer?

If yes, then this patch should fix it:

diff --git a/lisp/simple.el b/lisp/simple.el
index 47ce0364d1..7d91678ff7 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1517,6 +1517,7 @@ read-expression-map
     ;; Might as well bind TAB to completion, since inserting a TAB char is
     ;; much too rarely useful.
     (define-key m "\t" 'completion-at-point)
+    (define-key m [remap minibuffer-scroll-other-window] 'scroll-other-window)
     (set-keymap-parent m minibuffer-local-map)
     m))
 

Message #17 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: nvp <noah.v.peart <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50;
 minibuffer-scroll-other-window with multiple frames
Date: Thu, 5 Dec 2019 20:42:00 -0500

[Message part 1 (text/plain, inline)]

Is S-TAB referring to <backtab>?  That is unbound (default) in this context
for me.

I'm not sure where/if the behaviour was documented.  I think it has behaved
like that for
as long as I've used emacs, so it was quite noticeable that something was
different without knowing exactly what at first.

I just tried out v24.5 and C-M-v / C-M-S-v do scroll the completions buffer
with any number of frames up.

The recent change that sticks out to me is from 898cdc67f1

On Thu, Dec 5, 2019 at 7:19 PM Juri Linkov <juri <at> linkov.net> wrote:

> > I think this is new within the last week or so.
> > When a completion frame pops up while using the minibuffer,
> > normally the minibuffer-scroll-other-window(-down) functions
> > scroll the completion window.  However, now when emacs is split
> > into two horizontal frames, these functions ignore the
> > completion buffer and scroll the others.
> >
> > To reproduce from emacs -Q:
> >
> >     C-x 3
> >     M-: (mak
> >     TAB for completions
> >     C-M-v
>
> TAB and S-TAB should scroll the the completion buffer.  But what about
> C-M-v?
> Is it documented somewhere what buffer it's intended to scroll?
> I can find only this text in (info "(emacs) Minibuffer Edit"):
>
>      The ‘C-M-v’ command in the minibuffer scrolls the help text from
>   commands that display help text of any sort in another window.  You can
>   also scroll the help text with ‘M-<PageUp>’ and ‘M-<PageDown>’ (or,
>   equivalently, ‘M-<prior>’ and ‘M-<next>’).  This is especially useful
>   with long lists of possible completions.
>
> Does this mean the help text is the same as the completion buffer?
>
> If yes, then this patch should fix it:
>
> diff --git a/lisp/simple.el b/lisp/simple.el
> index 47ce0364d1..7d91678ff7 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -1517,6 +1517,7 @@ read-expression-map
>      ;; Might as well bind TAB to completion, since inserting a TAB char is
>      ;; much too rarely useful.
>      (define-key m "\t" 'completion-at-point)
> +    (define-key m [remap minibuffer-scroll-other-window]
> 'scroll-other-window)
>      (set-keymap-parent m minibuffer-local-map)
>      m))
>
>
>

[Message part 2 (text/html, inline)]

Message #20 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>, noah <noah.v.peart <at> gmail.com>
Cc: 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple
 frames
Date: Fri, 6 Dec 2019 08:37:20 +0100

> TAB and S-TAB should scroll the the completion buffer.  But what about C-M-v?
> Is it documented somewhere what buffer it's intended to scroll?

It should scroll 'minibuffer-selected-window' whichever buffer is
displayed there.

martin

Message #23 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: nvp <noah.v.peart <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38502 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#38502: 27.0.50;
 minibuffer-scroll-other-window with multiple frames
Date: Fri, 6 Dec 2019 03:04:35 -0500

[Message part 1 (text/plain, inline)]

I've noticed that the new completion windows can also become
much larger than they used to be, eg. covering nearly everything
completing after "(ma" for example.  I'm sure this is customizable,
but is there a general consensus on what/which real estate they
should take up?

I think leaving decent portions of the calling buffers can be quite
useful at times in order to "think as little as possible", eg.
avoid needing to check back to finish a though.

On Fri, Dec 6, 2019 at 2:37 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  > TAB and S-TAB should scroll the the completion buffer.  But what about
> C-M-v?
>  > Is it documented somewhere what buffer it's intended to scroll?
>
> It should scroll 'minibuffer-selected-window' whichever buffer is
> displayed there.
>
> martin
>

[Message part 2 (text/html, inline)]

Message #26 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: nvp <noah.v.peart <at> gmail.com>
Cc: 38502 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple
 frames
Date: Fri, 6 Dec 2019 09:36:21 +0100

> I've noticed that the new completion windows can also become
> much larger than they used to be, eg. covering nearly everything
> completing after "(ma" for example.  I'm sure this is customizable,
> but is there a general consensus on what/which real estate they
> should take up?

Are you sure this has changed "recently"?  If you have
'temp-buffer-resize-mode' enabled, the maximum height is specified by
the option 'temp-buffer-max-height'.  With 'temp-buffer-resize-mode'
disabled there is no such bound but I see no recent change in behavior
either.

> I think leaving decent portions of the calling buffers can be quite
> useful at times in order to "think as little as possible", eg.
> avoid needing to check back to finish a though.

Try with 'temp-buffer-resize-mode' enabled.  If you think that the
customization used there helps, we could try to implement something
similar when that mode is not enabled.

martin

Message #29 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: noah.v.peart <at> gmail.com, 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50;
 minibuffer-scroll-other-window with multiple frames
Date: Fri, 06 Dec 2019 09:48:34 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Date: Fri, 06 Dec 2019 02:02:53 +0200
> Cc: 38502 <at> debbugs.gnu.org
> 
> >     C-x 3
> >     M-: (mak
> >     TAB for completions
> >     C-M-v
> 
> TAB and S-TAB should scroll the the completion buffer.  But what about C-M-v?
> Is it documented somewhere what buffer it's intended to scroll?

It should scroll the window returned by other-window-for-scrolling.

Message #32 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: noah <noah.v.peart <at> gmail.com>, 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50; minibuffer-scroll-other-window with
 multiple frames
Date: Sun, 08 Dec 2019 01:33:12 +0200

>> TAB and S-TAB should scroll the the completion buffer.  But what about C-M-v?
>> Is it documented somewhere what buffer it's intended to scroll?
>
> It should scroll 'minibuffer-selected-window' whichever buffer is
> displayed there.

C-v and M-v should scroll 'minibuffer-selected-window', but
C-M-v should scroll the other window from 'minibuffer-selected-window'
like it does now.  But maybe this should be configurable?

Is there a variable/function with a name like 'minibuffer-selected-other-window'
that gives an other window to scroll with C-M-v from the minibuffer or
from the window defined by 'minibuffer-selected-window'?

Message #35 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: noah <noah.v.peart <at> gmail.com>, 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple
 frames
Date: Sun, 8 Dec 2019 09:58:07 +0100

> C-v and M-v should scroll 'minibuffer-selected-window', but
> C-M-v should scroll the other window from 'minibuffer-selected-window'
> like it does now.  But maybe this should be configurable?
>
> Is there a variable/function with a name like 'minibuffer-selected-other-window'
> that gives an other window to scroll with C-M-v from the minibuffer or
> from the window defined by 'minibuffer-selected-window'?

'other-window-for-scrolling' tries to dynamically find a window that
shows 'other-window-scroll-buffer'.  So it's the latter we would
probably have to set.

martin

Message #38 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: nvp <noah.v.peart <at> gmail.com>
Cc: 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50; minibuffer-scroll-other-window with
 multiple frames
Date: Sun, 08 Dec 2019 23:11:05 +0200

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

BTW, a related question:

    C-h f mak
    M-v

pops up and switches to the completion window, whereas

    M-: (mak
    M-v

doesn't.  Should it?

Message #41 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: noah <noah.v.peart <at> gmail.com>, 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50; minibuffer-scroll-other-window with
 multiple frames
Date: Mon, 09 Dec 2019 00:20:01 +0200

tags 38502 fixed
close 38502 27.0.50
quit

>> C-v and M-v should scroll 'minibuffer-selected-window', but
>> C-M-v should scroll the other window from 'minibuffer-selected-window'
>> like it does now.  But maybe this should be configurable?
>>
>> Is there a variable/function with a name like 'minibuffer-selected-other-window'
>> that gives an other window to scroll with C-M-v from the minibuffer or
>> from the window defined by 'minibuffer-selected-window'?
>
> 'other-window-for-scrolling' tries to dynamically find a window that
> shows 'other-window-scroll-buffer'.  So it's the latter we would
> probably have to set.

I see.  So this is fixed now.

Message #48 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>, nvp <noah.v.peart <at> gmail.com>
Cc: 38502 <at> debbugs.gnu.org
Subject: RE: bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple
 frames
Date: Sun, 8 Dec 2019 15:09:53 -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).

By default, Icicles uses `C-v' and `M-v' in the
minibuffer to scroll forward and backward, respectively.

Message #51 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: nvp <noah.v.peart <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: martin rudalics <rudalics <at> gmx.at>, 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50;
 minibuffer-scroll-other-window with multiple frames
Date: Sun, 8 Dec 2019 18:22:36 -0500

[Message part 1 (text/plain, inline)]

> Try with 'temp-buffer-resize-mode' enabled
Thankyou Martin, I was unaware of this and it does seem useful -- will
investigate further.

> Maybe <backtab> and S-TAB should do this.
To me, this does seem like a good idea.  The reasons being:
1) this would be my first natural guess to reverse a scroll, possibly from
muscle memory coming
from shift-tabbing between tabs (eg. browswers), which I think might be
rather ubiquitous (speculation)
2) it is similar to the addition of S to C-M-v nomal scrollers

be my first guess as a way to reverse a scroll, and it is also how C-M-v is
already reversed.

> pops up and switches to the completion window, whereas
>
>     M-: (mak
>     M-v
>
> doesn't.  Should it?

I  think it should, as M-v doesn't seem to have any use in the minibuffer
there AFAICT.

Thankyou !!!

On Sun, Dec 8, 2019 at 5:20 PM Juri Linkov <juri <at> linkov.net> wrote:

> tags 38502 fixed
> close 38502 27.0.50
> quit
>
> >> C-v and M-v should scroll 'minibuffer-selected-window', but
> >> C-M-v should scroll the other window from 'minibuffer-selected-window'
> >> like it does now.  But maybe this should be configurable?
> >>
> >> Is there a variable/function with a name like
> 'minibuffer-selected-other-window'
> >> that gives an other window to scroll with C-M-v from the minibuffer or
> >> from the window defined by 'minibuffer-selected-window'?
> >
> > 'other-window-for-scrolling' tries to dynamically find a window that
> > shows 'other-window-scroll-buffer'.  So it's the latter we would
> > probably have to set.
>
> I see.  So this is fixed now.
>

[Message part 2 (text/html, inline)]

Message #54 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: nvp <noah.v.peart <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: martin rudalics <rudalics <at> gmx.at>, 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50;
 minibuffer-scroll-other-window with multiple frames
Date: Sun, 8 Dec 2019 18:23:52 -0500

[Message part 1 (text/plain, inline)]

Ignore superfluous line
> be my first guess as a way to reverse a scroll, and it is also how C-M-v
is already reversed.

On Sun, Dec 8, 2019 at 6:22 PM nvp <noah.v.peart <at> gmail.com> wrote:

> > Try with 'temp-buffer-resize-mode' enabled
> Thankyou Martin, I was unaware of this and it does seem useful -- will
> investigate further.
>
> > Maybe <backtab> and S-TAB should do this.
> To me, this does seem like a good idea.  The reasons being:
> 1) this would be my first natural guess to reverse a scroll, possibly from
> muscle memory coming
> from shift-tabbing between tabs (eg. browswers), which I think might be
> rather ubiquitous (speculation)
> 2) it is similar to the addition of S to C-M-v nomal scrollers
>
> be my first guess as a way to reverse a scroll, and it is also how C-M-v
> is already reversed.
>
> > pops up and switches to the completion window, whereas
> >
> >     M-: (mak
> >     M-v
> >
> > doesn't.  Should it?
>
> I  think it should, as M-v doesn't seem to have any use in the minibuffer
> there AFAICT.
>
> Thankyou !!!
>
> On Sun, Dec 8, 2019 at 5:20 PM Juri Linkov <juri <at> linkov.net> wrote:
>
>> tags 38502 fixed
>> close 38502 27.0.50
>> quit
>>
>> >> C-v and M-v should scroll 'minibuffer-selected-window', but
>> >> C-M-v should scroll the other window from 'minibuffer-selected-window'
>> >> like it does now.  But maybe this should be configurable?
>> >>
>> >> Is there a variable/function with a name like
>> 'minibuffer-selected-other-window'
>> >> that gives an other window to scroll with C-M-v from the minibuffer or
>> >> from the window defined by 'minibuffer-selected-window'?
>> >
>> > 'other-window-for-scrolling' tries to dynamically find a window that
>> > shows 'other-window-scroll-buffer'.  So it's the latter we would
>> > probably have to set.
>>
>> I see.  So this is fixed now.
>>
>

[Message part 2 (text/html, inline)]

Message #57 received at 38502 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: nvp <noah.v.peart <at> gmail.com>, 38502 <at> debbugs.gnu.org
Subject: Re: bug#38502: 27.0.50; minibuffer-scroll-other-window with
 multiple frames
Date: Tue, 10 Dec 2019 01:39:32 +0200

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

Message #60 received at 38502 <at> debbugs.gnu.org (full text, mbox):

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