GNU bug report logs -
#17046
24.3.50; On startup emacs frame has no minibuffer or windows decorations
Previous Next
Reported by: Robert Marshall <robert <at> capuchin.co.uk>
Date: Thu, 20 Mar 2014 09:09:02 UTC
Severity: important
Found in version 24.3.50
Fixed in version 24.4
Done: Juanma Barranquero <lekktu <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #86 received at 17046 <at> debbugs.gnu.org (full text, mbox):
> 1) Put Emacs in the maximized state, or whatever is that is giving
> trouble (just one frame).
I don't understand - was it Robert's problem that he wanted to save the
Emacs desktop with a maximized frame? I only thought that _after
restoring_ the desktop, maximizing the frame didn't restore minibuffer
and title line.
So unless Robert says that this is the problem let's skip (1).
> 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.
> 5) paste the (setq desktop-saved-frameset ...) sexp into *scratch* and eval it
> 6) eval the following:
> (frameset-restore desktop-saved-frameset
> :reuse-frames t
> :cleanup-frames t
> :force-onscreen t)
>
> Then, repeat from 4) on, with the same desktop-saved-frameset value as
> before, but call frameset-restore with :force-onscreen nil (or without
> that line, nil is the default).
>
> Assuming that the problem reappears doing that, at least we have a
> frameset that causes it, and then we can look into it and try to
> understand what happens.
Thanks. This is what I had in mind with "deferring loading the desktop
file until you have seen your initial frame".
If we can repeat the problem this way, we can use the debugger.
martin
This bug report was last modified 11 years and 62 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.