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

From: martin rudalics <[email-masked]>
Date: Sat, 22 Mar 2014 19:43:20 +0100

> Can I just step back a bit, having been doing other things, I'm
 > rather confused as to what I'm being asked to do!

Sorry.  I'm at least as much confused as you.

 > I think before I
 > start doing to sequence of tests you've requested I need to get an
 > emacs which is showing a bad frame?

No.  We have to do something similar to restoring the frame which does
_not_ show the bad frame.  Let me try to explain (I'm afraid I'm not
very good at that).

With your original recipe you get a bad frame.  Unfortunately, we don't
know how to intercept that recipe, that is the frame restoration
procedure, in order to find out where things go wrong.  Nothing in the
dumps gives a useful hint.  Therefore we have to break up the original
monolithic recipe into various steps to find out where things go wrong.

Juanma's recipe is one such approach, simplified below:

(1) Copy the "(setq desktop-saved-frameset ...)" line from
     .emacs.desktop.  We presume that the inherent problem is somewhere
     hidden in that form.

(2) emacs -Q

(3) Paste the (setq desktop-saved-frameset ...) sexp into *scratch* and
     eval it.

(4) Eval the following:
    (frameset-restore desktop-saved-frameset
                      :reuse-frames t
                      :cleanup-frames t
                      :force-onscreen t)

Now apparently this fails as you mentioned in your other mail because
it's missing the remaining parts of .emacs.desktop like the buffers to
be shown in the windows.  I suppose this can be done easily by removing
just the

"(setq desktop-saved-frameset ...)"

form from .emas.desktop retaining everything else.  Please try to do
that, save the file but keep the original around, we might need it.
Then do (1)-(4) as above with one exception: Start emacs without the -Q
option in (2) to make sure the .emacs.desktop gets read.

Now this approach might produce a bad frame or not.  If it does, we can
proceed debugging `frameset-restore'.  If it doesn't after a few
attempts, stop testing.  Then we have restrained the problem to the fact
that `frameset-restore' breaks when working on the initial frame.

And before doing all this please wait until Juanma confirms that my new
recipe make sense at all.

martin