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

Previous Next

Package: emacs;

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 #128 received at 17046 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan <monnier <at> iro.umontreal.ca>
Cc: Juanma Barranquero <lekktu <at> gmail.com>,
 Robert Marshall <robert <at> capuchin.co.uk>, 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:21:32 +0100
> Having both is an error.
> We should have only one parameter.  It's too late to fix it 24.4, but we
> should fix it for 24.5.
>
> I think this parameter should be called `maximized' with values:
>
>    nil
>    width
>    height
>    t
>    fullscreen
>
> Is there some situation that is not covered by the above?

Yes.  On GNU/Linux maximize your frame, then type F11 twice.  What you
get is a maximized frame.  I presume this is the desired behavior.  To
get the same behavior on Windows you have to remember the state before
typing F11 the first time.

Note that F11 is not covered by the Windows API.  It's the application
that calculates the sizes and asks Windows to apply them, but as far as
Windows is concerned, a fullscreen is just the same as a normal window.
Now when we leave fullscreen mode we must somehow know whether to
restore to a maximized or a normal frame.  That's what the `maximized'
parameter is for - it remembers the previous state.

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.