GNU bug report logs - #17046
24.3.50; On startup emacs frame has no minibuffer or windows decorations

Previous Next

Full log

Message #386 received at 17046 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, robert <at> capuchin.co.uk,
 17046 <at> debbugs.gnu.org
Subject: Re: bug#17046: 24.3.50; On startup emacs frame has no minibuffer or
 windows decorations
Date: Wed, 26 Mar 2014 19:19:04 +0100

On Wed, Mar 26, 2014 at 6:54 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> My idea was what Robert did.  So it did work ;-)

Oh :-)

But that's equivalent to just skipping all the hoopla with
tool-bar-lines. You're setting it to 0, then to the correct value, and
then modifying the frame.

> Is it for some reason unworkable to have the size change after all the
> rest?

Presumably, that would break the fix for bug#14795.

OTOH, though the bug still real, i.e.,

  (modify-frame-parameters (make-frame) '((height . X)))

and

  (make-frame '((height . X)))

give frames of different size, now I cannot reproduce the problem when
restoring frames with frameset-restore *without* my workaround.

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.

Allow me a few hours to test things thoroughly.

    J

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.