bug-gnu-emacs
[Top][All Lists]
Advanced

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]