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

[Robert Marshall]

martin rudalics writes:
 >  > Yes, though I prefer using "emacs -Q -l file.el" because desktop does
 >  > many other things, like trying to restore modes, global and local
 >  > variables, etc.
 > 
 > OK.  But the problem is IMO that Robert ran this with a frameset derived
 > from the a saved desktop of the bad frame.  This won't reproduce the
 > problem because that frameset is likely OK (I did not see any
 > inconsistencies in the frame dump at least).  We have to run this with a
 > frameset derived from the original two windows frame.  I hope I attached
 > a correct version in my last mail, please have a look.
 > 

The frameset in Juanma's bug17046.el file only appeared to have one
window (in as far as I understand the format!) and I've just tried all
4 tests with the file (& frameset) that was attached to his email (adding a
find-file of .emacs) and one window (onto .emacs) appears and no sign
of the problem

So I've tried it with your version of bug17046.el (now with 2 find-files)

> Now if that frameset produces two windows as I expect, we know that the
 > problem is with transforming the initial Emacs frame, which apparently
 > is not good for restoring this desktop.  Then we have to step by step
 > remove lines from bug17046.el until we arrive at the line that causes
 > the problem.
 > 

This does produce 2 windows but in no case is there a sign of the
problem - or is that what you are expecting? I wondered about the

        (visibility . icon)

line (I don't think I ever started it up iconized) and tried the tests
both with and without it with the same result.

If I don't include the 2 find-files I get a single window onto *Messages*

Not sure whether it is relevant - or you've already assumed this
- there's no resize facility on the bad frame (apart from maximize) move
the mouse to the window corner and no resize arrows appear.

-- 
Robert Marshall