[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
bug#13937: 24.3.50; `make-frame' broken for `fullscreen' parameter on MS Windows
Wed, 13 Mar 2013 20:25:51 +0200
> From: "Drew Adams" <address@hidden>
> Cc: <address@hidden>
> 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
> 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
So I'm closing the bug.