bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations

[Juanma Barranquero <lekktu@gmail.com>]

On Wed, Mar 26, 2014 at 7:19 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

> I think there's been some changes related to frames and the like, so
> it is possible that the workaround can simply be removed and this
> problem just disappears. We would still have a bug with GTK builds and
> tool-bar-lines = 0, but it would be of much lesser impact.

OK, now I understand.

I originally added the tool-bar-lines stuff as a workaround for
bug#14795, which affects only newly created frames. That means that if
the frameset has a (height . 20) parameter for frame A, when restoring
the frameset, reusing a frame for A would work, but in case reusing
failed (no suitable frame found), A would be created with more than 20
lines (23 on Windows, for example). So the tool-bar-lines fix, to get
A back to 20 lines.

For several reasons related to offscreen frames, it turns out when a
new frame is needed, frameset-restore creates it invisible and
onscreen, and then reapplies its frame parameters and turns it visible
(if required). Which means that every new frame (the ones affected by
bug#14795) is already resized to the correct height while invisible,
regardless of whether it was the right height or not to start with.

In other words, I can remove the workaround for bug#14795 because it
is unnecessary now.

The GTK bug with (tool-bar-lines . 0) should be filed as a new bug,
IMHO, perhaps with a pointer to this one.