RE: resize-mini-windows...

["Drew Adams" <drew.adams@oracle.com>]

> > Why is the default value for `resize-mini-windows' `grow-only'?
> > I think that is annoying. I don't know what the advantage of
> > `grow-only' is supposed to be, but I don't think it is a good
> > choice for the default value.
>
> It's a fine compromise choice which offers the most important features,
> and avoids the most annoying problems of the alternatives.

Please explain what its advantages are, how it is better than the
alternatives, what the "annoying problems of the alternatives" are, and what
the "fine compromise" amounts to.

> This has been discussed many times, the default of `grow-only' is not
> some random choice.

I don't find any record of that discussion (or those "many" discussions).
Can you please point me to it?

> > What's wrong with t?
>
> There are fairly common situations where the resultant constant bouncing
> around of the window layout will drive you insane.  Think of times when
> many messages are output quickly, e.g when byte-compiling a directory:
> it's not unusual that half the messages are slightly longer than the
> display width...

Messages go in the echo area, not the minibuffer. What do they have to do
with the question?

> > or nil?
>
> Do you really think that's a good value?  Where every single message
> (and minibuffer edit!) over one line gets truncated?

I didn't realize that nil truncates. Why is that? Who would ever want that
behavior?

I figured that nil would give you the line-wrapping behavior of pre-Emacs
22. Is there no value of the option to give you that behavior? What was
wrong with that? It would make a fine default behavior (although I think the
t behavior is even better).

Please see the other points in my post, as well, including the two bugs (1
doc) I reported.