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

Previous Next

Full log

Message #48 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 13:49:49 +0300

> Date: Fri, 20 Apr 2012 12:01:57 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: rgm <at> gnu.org, 11276 <at> debbugs.gnu.org
> 
>  >>  >>  > (The manual also says:
>  >>  >>  >
>  >>  >>  >    You can resize it permanently by using the window sizing commands in
>  >>  >>  >    the frame's other window, when the minibuffer is not active.
>  >>  >>  >
>  >>  >>  > I don't know what this means. It doesn't seem to work in any version of
>  >>  >>  > Emacs that I can find.)
>  >>  >>
>  >>  >> The terminology "in the frame's other window" seems to indicate that
>  >>  >> this was written in an earlier century.
>  >>  >
>  >>  > How would you rephrase this for this century?
>  >>
>  >> Maybe "in a window adjacent to it"?
>  >
>  > What's the difference?
>  >
>  > Is your problem with the "window", in singular, or with something
>  > else, like "the frame"?
>  >
> 
> 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?

> It took me some while to find out that the other window must be a
> full height live window.

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

Previous Next

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