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

Previous Next

Full log

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 17046 <at> debbugs.gnu.org, Robert Marshall <robert <at> capuchin.co.uk>
Subject: Re: bug#17046: 24.3.50; On startup emacs frame has no minibuffer or
 windows decorations
Date: Thu, 20 Mar 2014 21:23:32 +0100

On Thu, Mar 20, 2014 at 8:24 PM, martin rudalics <rudalics <at> gmx.at> wrote:

> Obviously a total-height of 0 for FRAME 1 is broken - it should look
> like for FRAME 2.  Just that a total height of zero shouldn't have any
> bad consequences - it would get swallowed by `split-window'.

I checked, and it doesn't cause any trouble when restoring.

> And the
> differences in frameset--mini, are they OK?

>>     (frameset--mini t)
>>     (frameset--mini t . t)

Yes. The first t means that the frames have their own minibuffer. The
second t means that that frame's minibuffer was the one pointed out by
the `default-minibuffer-frame' variable. When restoring,
default-minibuffer-frame will be set to that frame, but that would
only affect new minibufferless frames, so it doesn't seem to have any
influence in the reported bug.

   J

Previous Next

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