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

[martin rudalics <rudalics@gmx.at>]

 >>   > 2) Exit Emacs (saving the desktop)
 >   >  > 3) Copy the "(setq desktop-saved-frameset ...)" line from .emacs.desktop
 >   >  > 4) emacs -Q
 >   >
 >   > Robert please try here both variants with and without -Q so we can see
 >   > whether something in your .emacs has any impact.
 >   >
 >
 > OK, I'm having problems at the moment getting it to replicate either
 > with a -Q -l loading:
 >       (desktop-save-mode 1)
 >       (setq desktop-save nil) ;; so that the desktop which was giving probs is kept!
 >       (desktop-read "/home/robert/tmp")

IIUC Juanma means that you must _not_ call `desktop-read' but rather
copy the

(setq desktop-saved-frameset ...)

form from your .emacs.desktop to *scratch* in the new emacs you just
started, evaluate that form and then do

    (frameset-restore desktop-saved-frameset
                      :reuse-frames t
                      :cleanup-frames t
                      :force-onscreen t)

in *scratch*.  If this does _not_ reproduce the problem after at most
two or three attempts I would conclude that the problem is with the
(Juanma might correct me) yet invisible frame used in the original
scenario by `desktop-read'.  For an invisible frame x_set_window_size_1
chooses the else clause in

   if (FRAME_VISIBLE_P (f))
     x_wait_for_event (f, ConfigureNotify);
   else
     {
       change_frame_size (f, width, height, 0, 1, 0, 1);
       x_sync (f);
     }

so there's no synchronization with the window manager right here and
maybe subsequently making the frame visible is not catching up with the
changes induced by change_frame_size.  This is the only conclusion I
currently have left.

So once more: If you can't reproduce the problem here with very few
attempts don't insist.  In this case we should try the following: Strip
your .emacs.desktop from any irrelevant entries.  This means to
construct a new .emacs.desktop that is sufficient to cause the original
problem and otherwise minimal enough so we can debug it.  Juanma: Can we
get a pretty printed version of Robert's .emacs.desktop such that he can
process it with `desktop-read' and we can comment out entries easily?
Then we could start in a first step do things like

;;      (foreground-color . "DarkOrchid1")
;;      (background-color . "mint cream")
;;      (mouse-color . "#221f1e")
;;      (border-color . "black")
;;      (screen-gamma)
;;      (line-spacing)
      (left-fringe . 8)
      (right-fringe . 8)
;;      (scroll-bar-foreground . "#221f1e")
;;      (scroll-bar-background . "grey75")
      (menu-bar-lines . 1)
      (tool-bar-lines . 1)
;;      (title)
      (wait-for-wm . t)
;;      (fullscreen)
      (tool-bar-position . top)
;;      (icon-type . t)
;;      (auto-raise)
;;      (auto-lower)
;;      (cursor-type . box)
      (scroll-bar-width . 16)
;;      (alpha . 90)
      (horizontal-scroll-bars . t)
;;      (display-type . color)
;;      (background-mode . light)
;;      (cursor-color . "#221f1e")
;;      (sticky)
;;      (environment)

Ideally we could comment out everything but the height and width entries
but I suppose we need some additional entry to produce the bug.  Any
such entry already should provide a first clue.

 > or with my normal .emacs will let you know when I manage to generate
 > the same problem again!

martin