[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13937: 24.3.50; `make-frame' broken for `fullscreen' parameter on MS
From: |
Eli Zaretskii |
Subject: |
bug#13937: 24.3.50; `make-frame' broken for `fullscreen' parameter on MS Windows |
Date: |
Wed, 13 Mar 2013 20:25:51 +0200 |
> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <13937@debbugs.gnu.org>
> Date: Wed, 13 Mar 2013 11:11:47 -0700
>
> > > A new frame is created with the same content (good).
> > > However:
> > >
> > > 1. There is no minibuffer shown.
> > > 2. The frame is not maximized.
> >
> > Fixed in trunk revision 112038. Thanks.
>
> Thanks; that was quick.
A clear bug with a simple recipe is easy to debug, and in this case
was also easy to fix.
> > > And you will see this entry (or similar):
> > > (minibuffer . #<window 03B1A3F8 on *Minibuf-0*>)
> > >
> > > That is not correct wrt the arg to `make-frame'.
> >
> > This part I don't get: why do you think this is incorrect?
>
> The arg passed to `make-frame' was t.
>
> Now perhaps you will say that it is correct that it substitutes a window for t
> in the actual value used. I can't speak to that (not documented AFAICT).
Yes, it is correct. Emacs always behaved like this, except that in
previous versions it would display a small number, a counter, instead
of a pointer to the window object.
> But the bug here is that there is (was) no minibuffer visible, even though
> (minibuffer . t) was included in the parameters passed to `make-frame'.
Ah, okay. Then that's fixed also. It was a result of not resizing
the frame.
> Well two things were broken visibly: the frame size and lack of visible
> minibuffer. Whether those are both due to the same underlying cause, I don't
> know.
They are.
So I'm closing the bug.