bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations

[Juanma Barranquero]

On Tue, Mar 25, 2014 at 12:09 PM, Robert Marshall <robert@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