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

Previous Next

Full log

Message #143 received at 17046 <at> debbugs.gnu.org (full text, mbox):

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

Juanma Barranquero writes:
 > On Fri, Mar 21, 2014 at 6:42 PM, martin rudalics <rudalics <at> gmx.at> wrote:
 > 
 > > Juanma must likely help now for the HOWTO:
 > 
 > I'm a bit lost here. What do you need from me?
 > 
 > > Can you reproduce the problem with an empty .emacs, just loading the
 > > desktop file.
 > >
 > > And can you try with your usual .emacs but deferring loading the desktop
 > > file until you have seen your initial frame.
 > 
 > One thing that Robert can try is:
 > 
 > 1) Put Emacs in the maximized state, or whatever is that is giving
 > trouble (just one frame).

OK I've managed to get a bad frame here, no window decorations but
there is a minibuffer visible (and not maximised)

> 2) Exit Emacs (saving the desktop)
 > 3) Copy the "(setq desktop-saved-frameset ...)" line from .emacs.desktop
 > 4) emacs -Q
 > 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).

I did all those (2,3 then 4-6) -the desktop-saved-frameset referenced buffers that
didn't exist - is that correct or should I have loaded them before
evaling the desktop-saved-frameset?

Then repeated (4-6) with :force-onscreen now nil

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

In neither case did the problem appear. What I am seeing on emacs -Q is

Ignoring unknown mode `16-mode'
Ignoring unknown mode `16-*-*-mode'

in *messages* - is this benign? They don't appear with -Q --no-site-file
but *info* says that -Q covers --no-site-file?

Robert
-- 
Robert Marshall

Previous Next

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