[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames
From: |
martin rudalics |
Subject: |
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
- bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames, (continued)
bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames, Eli Zaretskii, 2019/12/06
bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames, martin rudalics, 2019/12/06
bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames, Juri Linkov, 2019/12/07
bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames, martin rudalics, 2019/12/08
bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames, Juri Linkov, 2019/12/08
bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames, nvp, 2019/12/08
bug#38502: 27.0.50; minibuffer-scroll-other-window with multiple frames, nvp, 2019/12/08