GNU bug report logs - #17046
24.3.50; On startup emacs frame has no minibuffer or windows decorations

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Robert Marshall <robert <at> capuchin.co.uk>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 17046 <at> debbugs.gnu.org
Subject: bug#17046: 24.3.50; On startup emacs frame has no minibuffer or windows decorations
Date: Sat, 22 Mar 2014 14:44:57 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.