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

Previous Next

Full log

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

From: Robert Marshall <robert <at> capuchin.co.uk>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 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:14:00 +0000

Juanma Barranquero writes:
 > 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 :-)
 > 

I'm glad I put in both options!

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

Should I be updating my pull from bzr? (if only to keep in sync with you)

Robert
-- 
Robert Marshall

Previous Next

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