RE: resize-mini-windows...

[Drew Adams]

> > 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.
>
> I'm not going to get drawn into another one of your drawn-out Asberger's
> fests, Drew.  I already explained the reasons.

Leave the personal insults and projection behind, please.

You said only that it has been discussed many times (where?) and it
represents a fine compromise (= what?).

I searched the archives, but I didn't find much on this. I found the thread
that I introduced in January 2007 and a thread from 2003 about resizing of
the echo area being too eager: "[Annoyance] resizing of echo area is too
eager". I found no other pertinent mention of `resize-mini-windows' in
`emacs-devel' or `emacs-pretest', by searching gmane.

The "[Annoyance]" thread did indicate indirectly that `resize-mini-windows'
affects not only minibuffer size but also echo-area size, as you also
indicated by referring to output messages. This was news to me.

I don't see that explained in the doc anywhere. It's not obvious, given the
function name and a doc string that makes no mention of it, that this option
also controls echo-area resizing, that is, both input and output.

Also, as I said, I don't see this option mentioned in the Elisp manual. My
Emacs snapshot dates from January 25, so perhaps the doc was improved after
that date. Perhaps someone with a recent snapshot will check. I would expect
to see this option discussed in the same node as `max-mini-window-height'.

The "[Annoyance]" thread from 2003 pointed out that `grow-only' suffered
from the same problem reported there, that is, it is *not* a "fine
compromise", at least for the annoyance reported in that thread.

That thread mentions what I think is the same bug that I reported in
January: if 2 pixels more height are added by :boxing a character, the
minibuffer is resized (grown), but with a nil value the box is shown
completely (so no resizing should really be necessary here). In that
"[Annoyance]" thread, instead of a boxed character, it was a Korean
character with an ascent one point higher. This was the too-eager annoyance
reported. And `grow-only' did nothing to help it - only nil worked.

The explanation given for the bug was what I thought: resizing uses an
integral number of character lines. So, the annoyance will be there until we
either find a way to do fine-grained resizing or we allow a threshold (fudge
factor) before resizing. Using a reasonable threshold, vertical addition of
a mere pixel or two by :boxing, or addition of a mere point from an ascent
or descent, would not grow the window. As I said, the box shows completely
without resizing, but apparently the code insists that there be a certain
amount of blank space above and below. The fudge factor should take that
into account. (It could even be a user option, perhaps useful especially for
certain languages.)

I found no other discussion of `resize-mini-windows', so I don't know what
you're referring to - where was it "discussed many times"?

I propose that, as is currently (January, at least) stated (erroneously) in
the Elisp manual, t be the default value, not `grow-only'. Arguments
against?

Is there no way to get the pre-Emacs 22 behavior for the minibuffer, where
long input lines wrap, but there is otherwise no resizing? Setting the value
to nil stops vertical resizing (it is the only way to do that), but it also
truncates long input or a long message. Can we separate inhibition of
vertical resizing from truncation?