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

[martin rudalics]

>>   > 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