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

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

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

noah

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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: noah <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

noah
The snazzy new completion coloring is nice though!

On Thu, Dec 5, 2019 at 2:17 PM Eli Zaretskii <[hidden email]> wrote:
> From: noah <[hidden email]>
> 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.
Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by noah
> 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))
 




Reply | Threaded
Open this post in threaded view
|

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

noah
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 <[hidden email]> 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))


Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Juri Linkov-2
 > 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Juri Linkov-2
> From: Juri Linkov <[hidden email]>
> Date: Fri, 06 Dec 2019 02:02:53 +0200
> Cc: [hidden email]
>
> >     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.



Reply | Threaded
Open this post in threaded view
|

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

noah
In reply to this post by martin rudalics
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > 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



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by martin rudalics
>> 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'?



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
 > 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



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by noah
> 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?



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by martin rudalics
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.



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
In reply to this post by Juri Linkov-2
> > 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.



Reply | Threaded
Open this post in threaded view
|

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

noah
In reply to this post by Juri Linkov-2
> 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

noah
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 <[hidden email]> 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by 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.



Reply | Threaded
Open this post in threaded view
|

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.