bug#11276: minibuffers windows can no longer explictly be resized

bug#11276: minibuffers windows can no longer explictly be resized

[Glenn Morris]

Package: emacs
Version: 24.0.95

The Elisp manual "Introduction to Minibuffers" says:

    The minibuffer's window is normally a single line[...]. You can
    explicitly resize it temporarily with the window sizing commands; it
    reverts to its normal size when the minibuffer is exited.

In Emacs 23.4, it works to do:

emacs -Q
M-x C-x ^ C-x ^
   (the minibuffer window gets one line taller each time)

But in the current trunk, that has no effect.


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

bug#11276: minibuffers windows can no longer explictly be resized

[martin rudalics]

 > In Emacs 23.4, it works to do:
 >
 > emacs -Q
 > M-x C-x ^ C-x ^

Which command does this run?  I can't reasonably input "^" from the
command prompt here.

 >    (the minibuffer window gets one line taller each time)
 >
 > But in the current trunk, that has no effect.

Does it work if you set `resize-mini-windows' to nil?  If I do that
here, I can, for example, drag the divider between the emacs -Q main
window and the minibuffer window with the mouse.

 > (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.

martin

bug#11276: minibuffers windows can no longer explictly be resized

[Glenn Morris]

martin rudalics wrote:

>> M-x C-x ^ C-x ^
>
> Which command does this run?  I can't reasonably input "^" from the
> command prompt here.

C-x ^ runs enlarge-window

> Does it work if you set `resize-mini-windows' to nil?

No.

>  If I do that here, I can, for example, drag the divider between the
> emacs -Q main window and the minibuffer window with the mouse.

I can't seem to do that (GNU/Linux, lucid toolkit), no matter what the
value of resize-mini-windows is. Works in 23.4, not in trunk.

> The terminology "in the frame's other window" seems to indicate that
> this was written in an earlier century.

I didn't get that impression the first time I read it, but you could be
right.

bug#11276: minibuffers windows can no longer explictly be resized

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

 > C-x ^ runs enlarge-window

Silly binding.

 >> Does it work if you set `resize-mini-windows' to nil?
 >
 > No.

First bug.  I forgot that one can invoke `enlarge-window' and
`shrink-window' in the minibuffer window.  I'm not sure though whether these
should have any effect when `resize-mini-windows' is non-nil.

 >>  If I do that here, I can, for example, drag the divider between the
 >> emacs -Q main window and the minibuffer window with the mouse.
 >
 > I can't seem to do that (GNU/Linux, lucid toolkit), no matter what the
 > value of resize-mini-windows is. Works in 23.4, not in trunk.

Second bug (though it should work with >= 2 windows).  I misinterpreted
the semantics of `one-window-p'.

Please test the attached patch.  Resizing miniwindows was hardly tested,
unfortunately.

martin

[-- Attachment #2: resize-mini-window.diff --]
[-- Type: text/plain, Size: 1247 bytes --]

=== modified file 'lisp/mouse.el'
--- lisp/mouse.el	2012-01-19 07:21:25 +0000
+++ lisp/mouse.el	2012-04-19 08:24:05 +0000
@@ -408,7 +408,7 @@
 	  (and (eq line 'mode)
 	       (not resize-mini-windows)
 	       (eq (window-frame minibuffer-window) frame)
-	       (not (one-window-p t frame))
+	       (not (one-window-p t))
 	       (= (nth 1 (window-edges minibuffer-window))
 		  (nth 3 (window-edges window)))))
 	 (which-side

=== modified file 'lisp/window.el'
--- lisp/window.el	2012-04-11 02:36:04 +0000
+++ lisp/window.el	2012-04-19 10:22:56 +0000
@@ -2102,6 +2102,8 @@
    ((zerop delta))
    ((window-size-fixed-p nil horizontal)
     (error "Selected window has fixed size"))
+   ((and (window-minibuffer-p) (not horizontal))
+    (window--resize-mini-window (selected-window) delta))
    ((window--resizable-p nil delta horizontal)
     (window-resize nil delta horizontal))
    (t
@@ -2124,6 +2126,8 @@
    ((zerop delta))
    ((window-size-fixed-p nil horizontal)
     (error "Selected window has fixed size"))
+   ((and (window-minibuffer-p) (not horizontal))
+    (window--resize-mini-window (selected-window) (- delta)))
    ((window--resizable-p nil (- delta) horizontal)
     (window-resize nil (- delta) horizontal))
    (t

bug#11276: minibuffers windows can no longer explictly be resized

[Eli Zaretskii]

> Date: Thu, 19 Apr 2012 12:42:06 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 11276@debbugs.gnu.org
> 
> First bug.  I forgot that one can invoke `enlarge-window' and
> `shrink-window' in the minibuffer window.  I'm not sure though whether these
> should have any effect when `resize-mini-windows' is non-nil.

For compatibility with previous versions of Emacs, I think it
shouldn't, at least not on the emacs-24 branch.

resize-mini-windows is a misnomer: it actually means "mini-window size
is controlled by display engine".  That's why window-sizing commands
in previous versions never paid heed to it, only redisplay did.  And
that's why, quite counter-intuitively, setting it to _nil_ allows the
user to resize the mini-window.

We could make the implementation more in line with the name in future
versions, if we want, of course.

bug#11276: minibuffers windows can no longer explictly be resized

[Drew Adams]

> resize-mini-windows is a misnomer: it actually means "mini-window size
> is controlled by display engine".  That's why window-sizing commands
> in previous versions never paid heed to it, only redisplay did.  And
> that's why, quite counter-intuitively, setting it to _nil_ allows the
> user to resize the mini-window.
> 
> We could make the implementation more in line with the name in future
> versions, if we want, of course.

1. The right way to go is to decide first on the behavior you want.  Then base
the name on what it actually does.  If it needs to be renamed based on the
desired behavior then rename it, deprecating and temporarily aliasing the old
name.

It does not make much sense to instead design the behavior based on what the
name happens to be - unless that behavior is what you want anyway.  IOW, design
and name together; don't constrain the design to an existing name.

2. Wrt naming something that happens automatically (and possibly prevents or
overrides manual change by a user - in this case resizing): Use "auto" or
"automatic".  In this case, call it "autosize", "autoresize",
"automatic-(re)size", or some such.  That suggests that (a) the behavior is
automatic and (b) you might not be able to override it manually.

If the behavior of this option should be to allow automatic resizing (which
might or might not prevent manual resizing, depending on the design), then call
it something like "auto-resize-minibuffer" or "auto-resize-minibuf-window".

3. I've already said before that it is wrong to use only "mini" here.  This is
not just a mini-window, i.e., a small window - it is a minibuffer window.  See
bug #3320, deemed "wont-fix" by Lars:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3320.  Perhaps now that others
consider that `resize-mini-windows' is a misnomer (for additional reasons), this
misuse of "mini" can be reconsidered.

4. It might also be wrong (unnecessary for users) to refer here to minibuffer
window_s_ (plural).  In most contexts users do not need to know or care about
the existence of multiple minibuffer windows.  And in this case, unless the
option behavior does something specific that needs to call user attention to
multiple windows, Occam advises to just use the singular in the name.  Nuances,
if need be, can be pointed out in the doc.

5. And in this case it would perhaps not be inappropriate to refer to
auto-resizing of the minibuffer and not bother to add "window".  True, someone
using apropos for "window" would not find it, but a search for "minibuf" would:
`auto-resize-minibuffer'.

bug#11276: minibuffers windows can no longer explictly be resized

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

 >> First bug.  I forgot that one can invoke `enlarge-window' and
 >> `shrink-window' in the minibuffer window.  I'm not sure though whether these
 >> should have any effect when `resize-mini-windows' is non-nil.
 >
 > For compatibility with previous versions of Emacs, I think it
 > shouldn't, at least not on the emacs-24 branch.

Sorry, my formulation was probably unclear.  In Emas 23 you can often
resize the active minibuffer window manually (via `enlarge-window' or
`adjust-window-trailing-edge') regardless of the setting of
`resize-mini-windows'.  So should we keep that behavior or allow manual
resizing only when `resize-mini-windows' is nil?

 > resize-mini-windows is a misnomer: it actually means "mini-window size
 > is controlled by display engine".  That's why window-sizing commands
 > in previous versions never paid heed to it, only redisplay did.  And
 > that's why, quite counter-intuitively, setting it to _nil_ allows the
 > user to resize the mini-window.

The passive mini-window IIUC.

 > We could make the implementation more in line with the name in future
 > versions, if we want, of course.

That's another issue.

Please try the new patch I attached.  It should mimic the behavior of
Emacs 23 as close as possible.

martin

[-- Attachment #2: resize-mini-window.diff --]
[-- Type: text/plain, Size: 2770 bytes --]

=== modified file 'lisp/mouse.el'
--- lisp/mouse.el	2012-01-19 07:21:25 +0000
+++ lisp/mouse.el	2012-04-19 17:09:19 +0000
@@ -406,9 +406,11 @@
 		       (mouse-on-link-p start)))
 	 (enlarge-minibuffer
 	  (and (eq line 'mode)
-	       (not resize-mini-windows)
-	       (eq (window-frame minibuffer-window) frame)
-	       (not (one-window-p t frame))
+	       ;; Enlarge the minibuffer window iff it's either selected
+	       ;; or `resize-mini-windows' is nil.
+	       (or (not resize-mini-windows)
+		   (eq minibuffer-window (selected-window)))
+	       (not (one-window-p))
 	       (= (nth 1 (window-edges minibuffer-window))
 		  (nth 3 (window-edges window)))))
 	 (which-side

=== modified file 'lisp/window.el'
--- lisp/window.el	2012-04-11 02:36:04 +0000
+++ lisp/window.el	2012-04-19 17:09:12 +0000
@@ -1991,17 +1991,21 @@
 the left.  If the edge can't be moved by DELTA lines or columns,
 move it as far as possible in the desired direction."
   (setq window (window-normalize-window window))
-  (let ((frame (window-frame window))
-	(right window)
-	left this-delta min-delta max-delta)
+  (let* ((frame (window-frame window))
+	 (minibuffer-window (minibuffer-window frame))
+	 (right window)
+	 left this-delta min-delta max-delta)
     ;; Find the edge we want to move.
     (while (and (or (not (window-combined-p right horizontal))
 		    (not (window-right right)))
 		(setq right (window-parent right))))
     (cond
-     ((and (not right) (not horizontal) (not resize-mini-windows)
-	   (eq (window-frame (minibuffer-window frame)) frame))
-      (window--resize-mini-window (minibuffer-window frame) (- delta)))
+     ((and (not right) (not horizontal)
+	   ;; Resize the minibuffer window iff it's either active or
+	   ;; `resize-mini-windows' is nil. 
+	   (or (not resize-mini-windows)
+	       (eq minibuffer-window (selected-window))))
+      (window--resize-mini-window minibuffer-window (- delta)))
      ((or (not (setq left right)) (not (setq right (window-right right))))
       (if horizontal
 	  (error "No window on the right of this one")
@@ -2102,6 +2106,8 @@
    ((zerop delta))
    ((window-size-fixed-p nil horizontal)
     (error "Selected window has fixed size"))
+   ((and (window-minibuffer-p) (not horizontal))
+    (window--resize-mini-window (selected-window) delta))
    ((window--resizable-p nil delta horizontal)
     (window-resize nil delta horizontal))
    (t
@@ -2124,6 +2130,8 @@
    ((zerop delta))
    ((window-size-fixed-p nil horizontal)
     (error "Selected window has fixed size"))
+   ((and (window-minibuffer-p) (not horizontal))
+    (window--resize-mini-window (selected-window) (- delta)))
    ((window--resizable-p nil (- delta) horizontal)
     (window-resize nil (- delta) horizontal))
    (t

bug#11276: minibuffers windows can no longer explictly be resized

[Eli Zaretskii]

> Date: Thu, 19 Apr 2012 19:18:21 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, 11276@debbugs.gnu.org
> 
>  >> First bug.  I forgot that one can invoke `enlarge-window' and
>  >> `shrink-window' in the minibuffer window.  I'm not sure though whether these
>  >> should have any effect when `resize-mini-windows' is non-nil.
>  >
>  > For compatibility with previous versions of Emacs, I think it
>  > shouldn't, at least not on the emacs-24 branch.
> 
> Sorry, my formulation was probably unclear.

No, it was perfectly clear.  It's my wording that is confusing.  What
I meant to say is that, for compatibility, resize-mini-windows should
have no effect on "C-x ^" typed from the minibuffer window.

>  > resize-mini-windows is a misnomer: it actually means "mini-window size
>  > is controlled by display engine".  That's why window-sizing commands
>  > in previous versions never paid heed to it, only redisplay did.  And
>  > that's why, quite counter-intuitively, setting it to _nil_ allows the
>  > user to resize the mini-window.
> 
> The passive mini-window IIUC.

Yes.

bug#11276: minibuffers windows can no longer explictly be resized

[martin rudalics]

 >>  >> First bug.  I forgot that one can invoke `enlarge-window' and
 >>  >> `shrink-window' in the minibuffer window.  I'm not sure though whether these
 >>  >> should have any effect when `resize-mini-windows' is non-nil.
 >>  >
 >>  > For compatibility with previous versions of Emacs, I think it
 >>  > shouldn't, at least not on the emacs-24 branch.
 >>
 >> Sorry, my formulation was probably unclear.
 >
 > No, it was perfectly clear.  It's my wording that is confusing.  What
 > I meant to say is that, for compatibility, resize-mini-windows should
 > have no effect on "C-x ^" typed from the minibuffer window.

OK

 >>  > resize-mini-windows is a misnomer: it actually means "mini-window size
 >>  > is controlled by display engine".  That's why window-sizing commands
 >>  > in previous versions never paid heed to it, only redisplay did.  And
 >>  > that's why, quite counter-intuitively, setting it to _nil_ allows the
 >>  > user to resize the mini-window.
 >>
 >> The passive mini-window IIUC.
 >
 > Yes.

I checked in a fix similar to the one I posted earlier.  Please test it
with C-x ^ and modeline dragging.

Thanks, martin

bug#11276: minibuffers windows can no longer explictly be resized

[Eli Zaretskii]

> Date: Fri, 20 Apr 2012 12:01:22 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, 11276@debbugs.gnu.org
> 
> I checked in a fix similar to the one I posted earlier.  Please test it
> with C-x ^ and modeline dragging.

Seems to work fine, thanks.

bug#11276: minibuffers windows can no longer explictly be resized

[Glenn Morris]

martin rudalics wrote:

> I checked in a fix similar to the one I posted earlier.  Please test it
> with C-x ^ and modeline dragging.

Works for me; thanks.

bug#11276: minibuffers windows can no longer explictly be resized

[Eli Zaretskii]

> Date: Thu, 19 Apr 2012 08:56:54 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 11276@debbugs.gnu.org
> 
> Does it work if you set `resize-mini-windows' to nil?  If I do that
> here, I can, for example, drag the divider between the emacs -Q main
> window and the minibuffer window with the mouse.

This doesn't work for me, neither on the trunk nor on the emacs-24
branch.

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

bug#11276: minibuffers windows can no longer explictly be resized

[martin rudalics]

 >> Does it work if you set `resize-mini-windows' to nil?  If I do that
 >> here, I can, for example, drag the divider between the emacs -Q main
 >> window and the minibuffer window with the mouse.
 >
 > This doesn't work for me, neither on the trunk nor on the emacs-24
 > branch.

With a split frame you should be able to do that.

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

martin

bug#11276: minibuffers windows can no longer explictly be resized

[Eli Zaretskii]

> Date: Thu, 19 Apr 2012 19:23:02 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, 11276@debbugs.gnu.org
> 
>  >> Does it work if you set `resize-mini-windows' to nil?  If I do that
>  >> here, I can, for example, drag the divider between the emacs -Q main
>  >> window and the minibuffer window with the mouse.
>  >
>  > This doesn't work for me, neither on the trunk nor on the emacs-24
>  > branch.
> 
> With a split frame you should be able to do that.
> 
>  >>  > (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"?

bug#11276: minibuffers windows can no longer explictly be resized

[martin rudalics]

 >>  >>  > (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".  It took me some while to find out that the
other window must be a full height live window.

martin

bug#11276: minibuffers windows can no longer explictly be resized

[Eli Zaretskii]

> Date: Fri, 20 Apr 2012 12:01:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, 11276@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?

bug#11276: minibuffers windows can no longer explictly be resized

[martin rudalics]

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

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

martin

bug#11276: minibuffers windows can no longer explictly be resized

[Eli Zaretskii]

> Date: Fri, 20 Apr 2012 14:05:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, 11276@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.

bug#11276: minibuffers windows can no longer explictly be resized

[martin rudalics]

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

bug#11276: minibuffers windows can no longer explictly be resized

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 18 Apr 2012 21:04:05 -0400
> 
> (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.

This is inaccurate to the degree that it's exactly the other way
around: when the minibuffer _is_ active, you can use, e.g., the mouse
to drag the mode line above the minibuffer window and thus resize that
window.  When the minibuffer is not active, you can only do that if
resize-mini-windows (a misnomer, see my other mail) is nil.