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

Previous Next

Full log

View this message in rfc822 format

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

On Tue, Mar 25, 2014 at 12:09 PM, Robert Marshall <robert <at> capuchin.co.uk> wrote:

> It doesn't cause the bug

> Sometimes when I run that elisp (from *scratch*) I see the frame come
> up 80 width and it doesn't resize to 60 which seems odd (to me)

Not my area of expertise, but I'd bet a few eurocents both of these
must be caused by a race condition of some kind, where Emacs idea of
the frame state and the window manager's idea are desynchronized.
Creating and modifying frames is relatively slow. Bug#16967 is such a
case, on Windows.

> but if I drop those lines into a file and
> load it from a -Q -l command line I then see the bug.

That's wonderful, because we have finally decoupled the bug from
framesets (which makes things easier to test).

So, at the end, the bug is that modifying the dimensions of an
existing frame with tool-bar-lines set to 0 fails. That's either a
window manager problem, or a problem in the Emacs code related to it.

Adding a workaround for frameset.el is possible, but I'd like to know
if it's possible to fix the bug for real, because any workaround is
going to be ugly; I can't just disable the current code because I'd be
trading one bug for another.

Martin, any suggestion? Anyone else who knows about this stuff?

    J

Previous Next

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