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

Previous Next

Package: emacs;

Reported by: Robert Marshall <robert <at> capuchin.co.uk>

Date: Thu, 20 Mar 2014 09:09:02 UTC

Severity: important

Found in version 24.3.50

Fixed in version 24.4

Done: Juanma Barranquero <lekktu <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #401 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: Thu, 27 Mar 2014 00:05:29 +0100
On Wed, Mar 26, 2014 at 7:19 PM, Juanma Barranquero <lekktu <at> 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.




This bug report was last modified 11 years and 62 days ago.

Previous Next


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