Is S-TAB referring to ? 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 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-’ and ‘M-’ (or, > equivalently, ‘M-’ and ‘M-’). 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)) > > >