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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Robert Marshall <robert <at> capuchin.co.uk>
Cc: 17046 <at> debbugs.gnu.org
Subject: Re: bug#17046: 24.3.50;	On startup emacs frame has no minibuffer
 or windows decorations
Date: Fri, 21 Mar 2014 18:42:30 +0100

> Sorry for the confusion I've caused here - those 3 buttons belong to
> another application whose window I have shaded (so that the rest of it
> is not visible).

Ahh... OK.

> The emacs scroll bars and fringe disappear when the
> window gets the maximise command.

But they do so only on this "bad" frame, I suppose.  Maximizing a "good"
frame doesn't cause them to disappear.

> You mean before exiting emacs and that saving the desktop file and
> with an un'maximised' bad frame? I get (evaluating it in*scratch*)
> (see end of message - maybe I've misunderstood you here and you wanted
> the output with just one window in the bad frame - the output from
> that option is at the end)

You've done everything as I wanted, thanks.  This one reveals a strange
bug, namely in the last line of

> #<window 4 on  *Minibuf-0*>   parent: nil
> pixel left: 0   top: 630   size: 992 x 18   new: 0
> char left: 0   top: 35   size: 992 x 1   new: 240

instead of 992 the minibuffer window should have a character width of
124, like the other windows.  Unfortunately, this gives no clue at all
since we don't even record the minibuffer sizes in window states :-( I
suspect it's a problem the dump can't handle because at the time it
dumped the value the minibuffer was in an inconsistent state.

So all we have is a root window with 34 lines an upper window with 17
and a lower window with 18 lines and these get recorded correctly.

> So just one buffer in the frame split into 2 side by side windows
> (with the issues with two windows I'd been using split-window-below
> and displaying another buffer in the second window).......
>
> In attempting to restart to do this test I was unable to replicate the
> error for some time,

... which I expected ...

> I started emacs 3-4 times without the problem,
> eventually I got a bad frame and got the results below:

... which I didn't expect.  But again the values look correct and even
the minibuffer window has the correct char width now,

> #<window 4 on  *Minibuf-0*>   parent: nil
> pixel left: 0   top: 630   size: 992 x 18   new: 0
> char left: 0   top: 35   size: 124 x 1   new: 124

namely 124 as in 124 x 1.

> Restarted emacs and it came up with a bad frame, in case I misunderstood
> (1) here's window--dump-frame with just one window visible in the frame

And the frame dump reveals no problems.  I'm just as puzzled as before.

Juanma must likely help now for the HOWTO:

Can you reproduce the problem with an empty .emacs, just loading the
desktop file.

And can you try with your usual .emacs but deferring loading the desktop
file until you have seen your initial frame.

martin

Previous Next

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