bug#3300: 23.0.93; doc string of resize-mini-windows

bug#3300: 23.0.93; doc string of resize-mini-windows

[Drew Adams]

emacs -Q
 
The doc string says that a value of `grow-only':
 
"means let mini-windows grow only, until their display becomes empty,
at which point the windows go back to their normal size."
 
That is not what happens.
 
M-x hhhhhhhhhhhhh C-q C-j kkkkkkkkkkkkk C-q C-j mmmmmmmmmmmmmmmm
 
Then use backspace or whatever, to empty the minibuffer. The height
remains at the max height it was grown to. Same thing if you use `C-x
C-f' or anything else.
 
Either the doc is wrong or the product is wrong.
 
In GNU Emacs 23.0.93.1 (i386-mingw-nt5.1.2600)
 of 2009-05-02 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 

bug#3300: 23.0.93; doc string of resize-mini-windows

[Stefan Monnier]

> "means let mini-windows grow only, until their display becomes empty,
> at which point the windows go back to their normal size."
 
> That is not what happens.
 
> M-x hhhhhhhhhhhhh C-q C-j kkkkkkkkkkkkk C-q C-j mmmmmmmmmmmmmmmm
 
> Then use backspace or whatever, to empty the minibuffer.

IIUC your "empty minibuffer" is not the same as "their display becomes
empty".  E.g. your minibuffer still has a prompt and a cursor, so its
display is not empty.


        Stefan

bug#3300: 23.0.93; doc string of resize-mini-windows

[Drew Adams]

> > "means let mini-windows grow only, until their display 
> > becomes empty, at which point the windows go back to
> > their normal size."
>  
> > That is not what happens.
> > M-x hhhhhhhhhhhhh C-q C-j kkkkkkkkkkkkk C-q C-j mmmmmmmmmmmmmmmm
> > Then use backspace or whatever, to empty the minibuffer.
> 
> IIUC your "empty minibuffer" is not the same as "their display becomes
> empty".  E.g. your minibuffer still has a prompt and a cursor, so its
> display is not empty.

If "empty" here is really referring to a minibuffer with no prompt and no
cursor, then:

1. We should make that clear. It sounds like what is really meant is the
situation where the minibuffer window is inactive. If so, please make that
explicit.

2. Perhaps the default value should not be `grow-only'.

`grow-only' keeping the grown size until the user input is empty (which was my
misinterpretation of the doc string) might be reasonable. But if there is no
input in the minibuffer, then perhaps the grown size should not, by default, be
retained.

I'd sooner see `t' as the default value. But I don't use this, so perhaps others
should be polled.

In any case, the doc string should be made clear in this regard, wrt what
`grow-only' really means.

bug#3300: 23.0.93; doc string of resize-mini-windows

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> The doc string says that a value of `grow-only':
>
> "means let mini-windows grow only, until their display becomes empty,
> at which point the windows go back to their normal size."
>
> That is not what happens.
>
> M-x hhhhhhhhhhhhh C-q C-j kkkkkkkkkkkkk C-q C-j mmmmmmmmmmmmmmmm
>
> Then use backspace or whatever, to empty the minibuffer. The height
> remains at the max height it was grown to. Same thing if you use `C-x
> C-f' or anything else.

This looks like it has been fixed.  If I do the same, then the
minibuffer shrinks down after a half-second timeout, apparently.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#3300: 23.0.93; doc string of resize-mini-windows

[Drew Adams]

> This looks like it has been fixed.  If I do the same, then the
> minibuffer shrinks down after a half-second timeout, apparently.

Not in the latest build I have, at least:

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-06-27 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'

Perhaps this is platform-specific (Windows).
I see the same behavior - 100% reproducible.

Please do not reclassify a bug as not reproducible unless the user has confirmed
that it is fixed on his platform (or you cannot get in touch with the user
etc.).  There are many bugs that are platform-specific.  It is not enough to
give a quick test on one platform and then close a bug.

The primary goal should not be to close bugs, but to improve Emacs.

bug#3300: 23.0.93; doc string of resize-mini-windows

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

>> This looks like it has been fixed.  If I do the same, then the
>> minibuffer shrinks down after a half-second timeout, apparently.

[...]

> Perhaps this is platform-specific (Windows).
> I see the same behavior - 100% reproducible.

Ok; I've reopened the report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#3300: 23.0.93; doc string of resize-mini-windows

[Deniz Dogan]

On 2011-07-11 17:20, Lars Magne Ingebrigtsen wrote:
> "Drew Adams"<drew.adams@oracle.com>  writes:
>
>> The doc string says that a value of `grow-only':
>>
>> "means let mini-windows grow only, until their display becomes empty,
>> at which point the windows go back to their normal size."
>>
>> That is not what happens.
>>
>> M-x hhhhhhhhhhhhh C-q C-j kkkkkkkkkkkkk C-q C-j mmmmmmmmmmmmmmmm
>>
>> Then use backspace or whatever, to empty the minibuffer. The height
>> remains at the max height it was grown to. Same thing if you use `C-x
>> C-f' or anything else.
>
> This looks like it has been fixed.  If I do the same, then the
> minibuffer shrinks down after a half-second timeout, apparently.
>

Possibly slightly off-topic: is the `when' call really necessary in 
`resize-mini-window'?  The docstring says that WINDOW is a minibuffer 
window, so that seems like some sort of prerequisite to me.

bug#3300: 23.0.93; doc string of resize-mini-windows

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 11 Jul 2011 18:09:05 +0200
> Cc: 3300@debbugs.gnu.org
> 
> "Drew Adams" <drew.adams@oracle.com> writes:
> 
> >> This looks like it has been fixed.  If I do the same, then the
> >> minibuffer shrinks down after a half-second timeout, apparently.
> 
> [...]
> 
> > Perhaps this is platform-specific (Windows).
> > I see the same behavior - 100% reproducible.
> 
> Ok; I've reopened the report.

I think the behavior is correct, it's the doc string that needs to be
fixed.  What Drew expected happens when the value of the variable is
t, not `grow-only'.  The latter causes the minibuffer to shrink when
somebody or something writes an empty message there.

So I suggest to remove the part about shrinking when it becomes empty.

bug#3300: 23.0.93; doc string of resize-mini-windows

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> I think the behavior is correct, it's the doc string that needs to be
> fixed.  What Drew expected happens when the value of the variable is
> t, not `grow-only'.  The latter causes the minibuffer to shrink when
> somebody or something writes an empty message there.
>
> So I suggest to remove the part about shrinking when it becomes empty.

The docstring is already 100% clear IMO, but since the OP is apparently
not satisfied, I checked in a change to make it 105% clear.

bug#3300: 23.0.93; doc string of resize-mini-windows

[martin rudalics]

 > Possibly slightly off-topic: is the `when' call really necessary in
 > `resize-mini-window'?

You mean what is called `window--resize-mini-window' now?

 > The docstring says that WINDOW is a minibuffer
 > window, so that seems like some sort of prerequisite to me.

Sure.  But we often check whether an argument window is a window, an
argument frame a frame, or an argument buffer a buffer.  Sometimes up to
three or four times when executing a particular command.

martin

bug#3300: 23.0.93; doc string of resize-mini-windows

[Drew Adams]

> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think the behavior is correct, it's the doc string that 
> > needs to be fixed.

Yes.  (Which is why the Subject line says "doc string of...".)

> > What Drew expected happens when the value of the variable is
> > t, not `grow-only'.
> >
> > So I suggest to remove the part about shrinking when it 
> > becomes empty.

Yes, thank you.  That was the point.

> The docstring is already 100% clear IMO, but since the OP is 
> apparently not satisfied, I checked in a change to make it
> 105% clear.

A doc string that says that `grow-only' makes the "windows go back to their
normal size" is 100% wrong.

AFAIK, `grow-only' never returns minibuffer windows to their normal size during
a given invocation (reading of input).

The best that could be said is that "until their display becomes empty" is
unclear, and that something was meant other than the minibuffer being emptied
during its current invocation (input reading).