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

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Tue, 12 Mar 2013 22:38:01 UTC

Severity: normal

Found in version 24.3.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13937 in the body.
You can then email your comments to 13937 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#13937; Package emacs. (Tue, 12 Mar 2013 22:38:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Drew Adams" <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 12 Mar 2013 22:38:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.50; `make-frame' broken for `fullscreen' parameter on MS Windows
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.
 
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 <at> 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'
 





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#13937; Package emacs. (Wed, 13 Mar 2013 17:37:02 GMT) Full text and rfc822 format available.

Message #8 received at 13937 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 13937 <at> debbugs.gnu.org
Subject: Re: bug#13937: 24.3.50;
	`make-frame' broken for `fullscreen' parameter on MS Windows
Date: Wed, 13 Mar 2013 19:34:15 +0200
> From: "Drew Adams" <drew.adams <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#13937; Package emacs. (Wed, 13 Mar 2013 18:14:01 GMT) Full text and rfc822 format available.

Message #11 received at 13937 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 13937 <at> debbugs.gnu.org
Subject: RE: bug#13937: 24.3.50;
	`make-frame' broken for `fullscreen' parameter on MS Windows
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.

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





Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Wed, 13 Mar 2013 18:28:02 GMT) Full text and rfc822 format available.

Notification sent to "Drew Adams" <drew.adams <at> oracle.com>:
bug acknowledged by developer. (Wed, 13 Mar 2013 18:28:02 GMT) Full text and rfc822 format available.

Message #16 received at 13937-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 13937-done <at> debbugs.gnu.org
Subject: Re: 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 <at> oracle.com>
> Cc: <13937 <at> 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.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 11 Apr 2013 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 11 years and 29 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.