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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
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:17:12 +0300

> Date: Fri, 20 Apr 2012 14:05:57 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: rgm <at> gnu.org, 11276 <at> debbugs.gnu.org
> 
>  >> What does a term like "the frame's other window" mean?  A frame can have
>  >> a couple of "other windows".
>  >
>  > Would it be better if we said "the frame's other windows", in plural?
> 
> No.

Why not?

>  > ??? I can resize the minibuffer window like this:
>  >
>  >   emacs -Q
>  >   M-: (setq resize-mini-windows nil) RET
>  >   C-x 2
>  >   drag the mode line of the lowest window with the mouse
>  >
>  > What is the recipe where you must have a full-height window above the
>  > minibuffer?
> 
> Unplug your mouse ;-)
> 
> For example,
> 
>    emacs -Q
>    M-: (setq resize-mini-windows nil) RET
>    C-x 2
>    C-x o
>    M-x shrink-window

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.

Previous Next

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