bug#13937: 24.3.50; `make-frame' broken for `fullscreen' parameter on MS Windows

bug#13937: 24.3.50; `make-frame' broken for `fullscreen' parameter on MS Windows

[Drew Adams]

emacs -Q
 
In *scratch*, type this:
 
(defun foo ()
  (interactive)
  (select-frame (make-frame '((minibuffer . t)
                              (fullscreen . maximized)))))
  
(frame-parameters)
 
Evaluate the `foo' definition, then M-x foo.
 
A new frame is created with the same content (good).
However:
 
1. There is no minibuffer shown.
2. The frame is not maximized.
 
Nevertheless, go to eob (put point after `(frame-parameters)'), and
enter this (there will be no echo, so type carefully):
 
M-x pp-eval-last-sexp RET
 
You will see the frame parameters for the created frame.  Among them you
will see this parameter entry, which is correct (though the frame is NOT
maximized): (fullscreen . maximized).
 
And you will see this entry (or similar):
(minibuffer . #<window 03B1A3F8 on  *Minibuf-0*>)

That is not correct wrt the arg to `make-frame'.  And note that there is still
no minibuffer visible in this frame.  So if, e.g., you try to use Isearch, you
will not see the minibuffer (but Isearch will work OK).
 
Nor is the minibuffer window for the new frame on some other frame (which would
be wrong too).
 
It seems that multiple things are broken, here.  And the same thing
holds if you specify `fullboth' instead of `maximized'.
 
Note, however, that this works fine:
 
M-: (set-frame-parameter nil 'fullscreen 'maximized) ; or fullboth
 
As does this:
 
(modify-frame-parameters nil '((fullscreen . maximized)))
 
And this command too works fine (same as `foo', except for parameter
`fullscreen'):
 
(defun bar ()
  (interactive)
  (select-frame (make-frame '((minibuffer . t)))))
 
But `make-frame' seems quite broken.
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2013-03-04 on ODIEONE
Bzr revision: 111935 yamaoka@jpl.org-20130304102733-4qy111z41qwoh2as
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
 

bug#13937: 24.3.50; `make-frame' broken for `fullscreen' parameter on MS Windows

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 12 Mar 2013 15:21:31 -0700
> 
> emacs -Q
>  
> In *scratch*, type this:
>  
> (defun foo ()
>   (interactive)
>   (select-frame (make-frame '((minibuffer . t)
>                               (fullscreen . maximized)))))
>   
> (frame-parameters)
>  
> Evaluate the `foo' definition, then M-x foo.
>  
> 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.

> Nevertheless, go to eob (put point after `(frame-parameters)'), and
> enter this (there will be no echo, so type carefully):
>  
> M-x pp-eval-last-sexp RET
>  
> You will see the frame parameters for the created frame.  Among them you
> will see this parameter entry, which is correct (though the frame is NOT
> maximized): (fullscreen . maximized).
>  
> 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?

> It seems that multiple things are broken, here.

Only one thing was broken, actually: the new frame dimensions were
stored, but the frame was not being resized.

bug#13937: 24.3.50; `make-frame' broken for `fullscreen' parameter on MS Windows

[Drew Adams]

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

> > Nevertheless, go to eob (put point after `(frame-parameters)'), and
> > enter this (there will be no echo, so type carefully):
> >  
> > M-x pp-eval-last-sexp RET
> >  
> > You will see the frame parameters for the created frame.  
> > Among them you will see this parameter entry, which is correct
> > (though the frame is NOT maximized): (fullscreen . maximized).
> >  
> > 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).

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

> > It seems that multiple things are broken, here.
> 
> Only one thing was broken, actually: the new frame dimensions were
> stored, but the frame was not being resized.

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.

I guess you've understood this, and that everything has now been fixed.  If
there is still some confusion about the symptoms, please let me know.

bug#13937: 24.3.50; `make-frame' broken for `fullscreen' parameter on MS Windows

[Eli Zaretskii]

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