Subject: Re: bug#37609: Tool-bar-mode grows the frame's height

From: martin rudalics <[email-masked]>
Date: Sat, 5 Oct 2019 20:11:06 +0200

>  > OTOH, in a new session again with emacs -Q -f tool-bar-mode
 > [...]
 >  >    (tool-bar-mode 1)
 >
 > This changes the outer frame size (also on Windows) which it shouldn't do.
 > I'll look into it.

As a matter of fact, the behavior you see _is_ the intended one.  On
platforms where Emacs draws the tool bar into the frame (Lucid, Motif,
Windows) it has to (1) first trigger redisplay into drawing the tool
bar at least once so to get its real height and then (2) resize the
frame accordingly so it gets the requested initial number of lines.

This means that with

 > emacs -Q -f tool-bar-mode
 >
 > that disables tool-bar-mode before it's displayed for the first time,

no tool bar gets drawn,

 > and evaluating
 >
 > (let ((initial (assq 'outer-size (frame-geometry))))
 >    (tool-bar-mode 1)

this triggers the resizing of the frame to give it the desired number
of initial lines when a tool bar is present, and

 >    (tool-bar-mode 0)
 >    (list (assq 'outer-size (frame-geometry)) initial))

does _not_ size the frame back because that's the way toggling the
tool bar behaves ever since on the platforms cited above.  The same
holds for the behavior you described as

 > => ((outer-size 680 . 693) (outer-size 680 . 676))
 >
 > indicates growing of the frame's height.
 >
 > Evaluating the same again produces the correct result:
 >
 > => ((outer-size 680 . 693) (outer-size 680 . 693))
 >
 > OTOH, in a new session again with emacs -Q -f tool-bar-mode
 >
 > (progn
 >    (tool-bar-mode 1)
 >    (assq 'outer-size (frame-geometry)))
 >
 > => (outer-size 680 . 693)
 >
 > (progn
 >    (tool-bar-mode 0)
 >    (assq 'outer-size (frame-geometry)))
 >
 > => (outer-size 680 . 693)
 >
 > It's strange that the results are the same because visually
 > the frame's height grows.

The frame grows in both cases to 693 pixels when the tool bar is drawn
for the first time and never resizes afterwards (even when the tool
bar wraps).

We probably could suppress such untimely growing by tricking the code
into believing that the tool bar has already been drawn at least once
even if it was not drawn at all.  But I'm not sure whether such a
change could break runs where showing the tool bar might be delayed
for some reason.  Getting the 'frame-inhibit-implied-resize' stuff
perform sufficiently well was quite tricky.  So is the behavior we see
here annoying enough to warrant such a change?

martin