GNU bug report logs - #11276
minibuffers windows can no longer be explicitly resized

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11276 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#11276: minibuffers windows can no longer explictly be resized
Date: Fri, 20 Apr 2012 17:31:32 +0200

>>  > Would it be better if we said "the frame's other windows", in plural?
>>
>> No.
>
> Why not?

Because the other windows might be of no help here, see below.

> OK, but that's just the side effect of how shrink-window works, the
> mouse way proves that it _is_ possible to resize the minibuffer window
> even if the window above it is not full-height.

We know that resizing the minibuffer window works because the display
code does it all the time.  The mouse way doesn't prove anything
additional because modeline dragging works regardless of the window I'm
in.  The idea of the original text

   You can resize it permanently by using the window sizing commands in
   the frame's other window, when the minibuffer is not active.

was that there is only _one_ other window and in that case shrinking or
enlarging that window via `enlarge-window' indeed resizes the minibuffer
window.  If, however, I'm not in a full-height window, shrinking or
enlarging that window will not resize the minibuffer window.  So the
original text is misleading.  Programmatically, it's obviously more
simple to use

(window-resize (minibuffer-window) 1)

martin

Previous Next

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