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

Previous Next

Full log

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

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

> Please clarify. Do you mean:
>
> - Not to restore upon a non-strictly visible frame (and so choose
> another or create a new one)?
> - To wait until the frame is visible?

The latter, I'd say.

> (I'm not sure what do you mean with "strictly visible", BTW).

"Strictly visible" should stand for "always visible while desktop
restoration is done".

> The :reuse-frames arg of `frameset-restore' accepts a predicate, so if
> you have a way to decide from Elisp that a frame is "strictly
> visible", you can allow or disallow its reusing.

I meant to find some way where we, before restoring a desktop, make the
involved frame visible and then do the restoring, so the user "sees"
what happens.  This obviously works only when a frame exists already
before restoration kicks in, but IIUC this is what happens in Robert's
case.

martin

Previous Next

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