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

[Juanma Barranquero]

On Sat, Mar 22, 2014 at 2:44 PM, martin rudalics <rudalics@gmx.at> wrote:

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

Correct. This is the way to know if it happens *after* the original
frame is created and visible.

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

And in that case, what I would suggest is to create a file

;;; bug17046.el ;;;
(setq desktop-saved-frameset ...)
(frameset-restore desktop-saved-frameset
                  :reuse-frames t
                  :cleanup-frames t
                  :force-onscreen t)
;;; end ;;;

and then try

   emacs -Q -l bug17046.el

(and the same with :force-onscreen nil).

Note: if the problem depends on the original frame having more than
one window (before the restore, I mean), then these windows should be
created in bug17046.el before calling `frameset-restore', of course.
Same for having several buffers, etc. But as a first test, the above
should suffice


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

I'm not sure which one right now, but assuming the last, which he said
showed the bug, the attached file should be enough.

   J

bug17046.el
Description: Binary data