unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#11276: minibuffers windows can no longer explictly be resized
@ 2012-04-19  1:04 Glenn Morris
  2012-04-19  6:56 ` martin rudalics
  2012-04-19 14:28 ` Eli Zaretskii
  0 siblings, 2 replies; 20+ messages in thread
From: Glenn Morris @ 2012-04-19  1:04 UTC (permalink / raw)
  To: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19  1:04 bug#11276: minibuffers windows can no longer explictly be resized Glenn Morris
@ 2012-04-19  6:56 ` martin rudalics
  2012-04-19  7:12   ` Glenn Morris
  2012-04-19 14:31   ` Eli Zaretskii
  2012-04-19 14:28 ` Eli Zaretskii
  1 sibling, 2 replies; 20+ messages in thread
From: martin rudalics @ 2012-04-19  6:56 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 11276

 > 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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19  6:56 ` martin rudalics
@ 2012-04-19  7:12   ` Glenn Morris
  2012-04-19 10:42     ` martin rudalics
  2012-04-19 14:31   ` Eli Zaretskii
  1 sibling, 1 reply; 20+ messages in thread
From: Glenn Morris @ 2012-04-19  7:12 UTC (permalink / raw)
  To: martin rudalics; +Cc: 11276

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.





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19  7:12   ` Glenn Morris
@ 2012-04-19 10:42     ` martin rudalics
  2012-04-19 14:37       ` Eli Zaretskii
  0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2012-04-19 10:42 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 11276

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19  1:04 bug#11276: minibuffers windows can no longer explictly be resized Glenn Morris
  2012-04-19  6:56 ` martin rudalics
@ 2012-04-19 14:28 ` Eli Zaretskii
  1 sibling, 0 replies; 20+ messages in thread
From: Eli Zaretskii @ 2012-04-19 14:28 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19  6:56 ` martin rudalics
  2012-04-19  7:12   ` Glenn Morris
@ 2012-04-19 14:31   ` Eli Zaretskii
  2012-04-19 17:23     ` martin rudalics
  1 sibling, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2012-04-19 14:31 UTC (permalink / raw)
  To: martin rudalics; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19 10:42     ` martin rudalics
@ 2012-04-19 14:37       ` Eli Zaretskii
  2012-04-19 15:13         ` Drew Adams
  2012-04-19 17:18         ` martin rudalics
  0 siblings, 2 replies; 20+ messages in thread
From: Eli Zaretskii @ 2012-04-19 14:37 UTC (permalink / raw)
  To: martin rudalics; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19 14:37       ` Eli Zaretskii
@ 2012-04-19 15:13         ` Drew Adams
  2012-04-19 17:18         ` martin rudalics
  1 sibling, 0 replies; 20+ messages in thread
From: Drew Adams @ 2012-04-19 15:13 UTC (permalink / raw)
  To: 'Eli Zaretskii', 'martin rudalics'; +Cc: 11276

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






^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19 14:37       ` Eli Zaretskii
  2012-04-19 15:13         ` Drew Adams
@ 2012-04-19 17:18         ` martin rudalics
  2012-04-20  7:43           ` Eli Zaretskii
  1 sibling, 1 reply; 20+ messages in thread
From: martin rudalics @ 2012-04-19 17:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 11276

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



^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19 14:31   ` Eli Zaretskii
@ 2012-04-19 17:23     ` martin rudalics
  2012-04-20  7:47       ` Eli Zaretskii
  0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2012-04-19 17:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19 17:18         ` martin rudalics
@ 2012-04-20  7:43           ` Eli Zaretskii
  2012-04-20 10:01             ` martin rudalics
  0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2012-04-20  7:43 UTC (permalink / raw)
  To: martin rudalics; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-19 17:23     ` martin rudalics
@ 2012-04-20  7:47       ` Eli Zaretskii
  2012-04-20 10:01         ` martin rudalics
  0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2012-04-20  7:47 UTC (permalink / raw)
  To: martin rudalics; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-20  7:43           ` Eli Zaretskii
@ 2012-04-20 10:01             ` martin rudalics
  2012-04-20 10:16               ` Eli Zaretskii
  2012-04-21  1:01               ` Glenn Morris
  0 siblings, 2 replies; 20+ messages in thread
From: martin rudalics @ 2012-04-20 10:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-20  7:47       ` Eli Zaretskii
@ 2012-04-20 10:01         ` martin rudalics
  2012-04-20 10:49           ` Eli Zaretskii
  0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2012-04-20 10:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-20 10:01             ` martin rudalics
@ 2012-04-20 10:16               ` Eli Zaretskii
  2012-04-21  1:01               ` Glenn Morris
  1 sibling, 0 replies; 20+ messages in thread
From: Eli Zaretskii @ 2012-04-20 10:16 UTC (permalink / raw)
  To: martin rudalics; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-20 10:01         ` martin rudalics
@ 2012-04-20 10:49           ` Eli Zaretskii
  2012-04-20 12:05             ` martin rudalics
  0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2012-04-20 10:49 UTC (permalink / raw)
  To: martin rudalics; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-20 10:49           ` Eli Zaretskii
@ 2012-04-20 12:05             ` martin rudalics
  2012-04-20 14:17               ` Eli Zaretskii
  0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2012-04-20 12:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-20 12:05             ` martin rudalics
@ 2012-04-20 14:17               ` Eli Zaretskii
  2012-04-20 15:31                 ` martin rudalics
  0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2012-04-20 14:17 UTC (permalink / raw)
  To: martin rudalics; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-20 14:17               ` Eli Zaretskii
@ 2012-04-20 15:31                 ` martin rudalics
  0 siblings, 0 replies; 20+ messages in thread
From: martin rudalics @ 2012-04-20 15:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 11276

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





^ permalink raw reply	[flat|nested] 20+ messages in thread

* bug#11276: minibuffers windows can no longer explictly be resized
  2012-04-20 10:01             ` martin rudalics
  2012-04-20 10:16               ` Eli Zaretskii
@ 2012-04-21  1:01               ` Glenn Morris
  1 sibling, 0 replies; 20+ messages in thread
From: Glenn Morris @ 2012-04-21  1:01 UTC (permalink / raw)
  To: martin rudalics; +Cc: 11276

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.





^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2012-04-21  1:01 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-19  1:04 bug#11276: minibuffers windows can no longer explictly be resized Glenn Morris
2012-04-19  6:56 ` martin rudalics
2012-04-19  7:12   ` Glenn Morris
2012-04-19 10:42     ` martin rudalics
2012-04-19 14:37       ` Eli Zaretskii
2012-04-19 15:13         ` Drew Adams
2012-04-19 17:18         ` martin rudalics
2012-04-20  7:43           ` Eli Zaretskii
2012-04-20 10:01             ` martin rudalics
2012-04-20 10:16               ` Eli Zaretskii
2012-04-21  1:01               ` Glenn Morris
2012-04-19 14:31   ` Eli Zaretskii
2012-04-19 17:23     ` martin rudalics
2012-04-20  7:47       ` Eli Zaretskii
2012-04-20 10:01         ` martin rudalics
2012-04-20 10:49           ` Eli Zaretskii
2012-04-20 12:05             ` martin rudalics
2012-04-20 14:17               ` Eli Zaretskii
2012-04-20 15:31                 ` martin rudalics
2012-04-19 14:28 ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).