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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#13937: closed (24.3.50; `make-frame' broken for `f


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#13937: closed (24.3.50; `make-frame' broken for `fullscreen' parameter on MS Windows)
Date: Wed, 13 Mar 2013 18:28:02 +0000

Your message dated Wed, 13 Mar 2013 20:25:51 +0200
with message-id <address@hidden>
and subject line Re: bug#13937: 24.3.50; `make-frame' broken for `fullscreen' 
parameter on MS Windows
has caused the debbugs.gnu.org bug report #13937,
regarding 24.3.50; `make-frame' broken for `fullscreen' parameter on MS Windows
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
13937: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13937
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- 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 address@hidden
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'
 




--- End Message ---
--- Begin Message --- 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" <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
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.


--- End Message ---

reply via email to

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