resize-mini-windows

resize-mini-windows

[Drew Adams]

1. Shouldn't user option `resize-mini-windows' be documented in Elisp manual
node Intro to Minibuffers, where the resizing is explained? That is,
shouldn't we tell users that (and how) they can control the resizing?

2. With `resize-mini-windows' = `grow-only' (the default), if I put a face
on a character in the minibuffer prompt, and the face has a :box with
1-pixel border, then the minibuffer grows about a character in height.

That seems unnecessary - why should 2 more pixels in height necessitate such
a gross resizing? I guess the answer is that frames and windows must be an
integral number of characters in height. But it still seems odd.

If I set `resize-mini-windows' = nil, the boxed character is shown
completely, including both top and bottom box borders, so I don't think the
resizing is because "the contents require more space" (from the doc).
Something seems wrong with the computation of the needed height. Unless,
that is, an additional space is supposed to always be present above and
below the displayed characters.

The Elisp manual also says, to introduce the idea of resizing, "The
minibuffer's window is normally a single line..." It should say "The
minibuffer's height is that of a single line", because as it stands now it
gives the impression that additional lines are added during resizing. In
what I see, there is still only a single minibuffer line (single line of
text), but the minibuffer height is increased.

FYI, this is the face I put on a character, to provoke the jump in height:

(defface foo
    '((((type x w32 mac graphic) (class color))
       (:box (:line-width 1 :color "Red") :foreground "Red" :background
"Cyan"))
      (t (:inverse-video t)))
  "..." :group 'faces)

If I use a standalone minibuffer frame, I see no change in height, BTW.
Perhaps that is because there is sufficient height already; I'm not sure.

Re: resize-mini-windows

[Richard Stallman]

    1. Shouldn't user option `resize-mini-windows' be documented in Elisp manual
    node Intro to Minibuffers, where the resizing is explained? That is,
    shouldn't we tell users that (and how) they can control the resizing?

It is documented in Minibuffer Edit.  That seems fine.

RE: resize-mini-windows...

[Drew Adams]

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. What's
wrong with t? or nil?

Also, the Emacs manual (at least in my January snapshot), node Minibuffer
Edit, says that t is the default value. Would that it were... (apologies to
J. Kerry).

Also, the Elisp manual does not mention `resize-mini-windows'. It should, I
think, be mentioned in node Minibuffer Misc, which describes other
minibuffer variables, such as `max-mini-window-height'.

Also, shouldn't `max-mini-window-height' be named something like
`minibuffer-window-max-height' - that is, shouldn't `max' be next to
`height' and `minibuffer' be next to `window'?

Also, what about this bug:

> From: Drew Adams Sent: Monday, January 08, 2007 3:24 PM
...
> 2. With `resize-mini-windows' = `grow-only' (the default), if I put a face
> on a character in the minibuffer prompt, and the face has a :box with
> 1-pixel border, then the minibuffer grows about a character in height.
...
> If I set `resize-mini-windows' = nil, the boxed character is shown
> completely, including both top and bottom box borders, so I don't
> think the resizing is because "the contents require more space" (from the
> doc). Something seems wrong with the computation of the needed height.
> Unless, that is, an additional space is supposed to always be present
> above and below the displayed characters.
...
> FYI, this is the face I put on a character, to provoke the jump in height:
> (defface foo
>     '((((type x w32 mac graphic) (class color))
>        (:box (:line-width 1 :color "Red")
>         :foreground "Red" :background "Cyan"))
>       (t (:inverse-video t)))
>   "..." :group 'faces)

Re: resize-mini-windows...

[Miles Bader]

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

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

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

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

> or nil?

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


-Miles

-- 
What the fuck do white people have to be blue about!?  Banana Republic ran
out of Khakis?  The Espresso Machine is jammed?  Hootie and The Blowfish are
breaking up??!  Shit, white people oughtta understand, their job is to GIVE
people the blues, not to get them!    -- George Carlin

RE: resize-mini-windows...

[Drew Adams]

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

Re: resize-mini-windows...

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> 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.

-Miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'

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?