GNU bug report logs -
#10120
24.0.91; frame-visible-p returns t, but frame not visible/iconified
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Wed, 23 Nov 2011 17:46:01 UTC
Severity: normal
Tags: moreinfo
Found in version 24.0.91
Done: Glenn Morris <rgm <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 10120 in the body.
You can then email your comments to 10120 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10120
; Package
emacs
.
(Wed, 23 Nov 2011 17:46: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
.
(Wed, 23 Nov 2011 17:46:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Probably not very useful as is - sorry about that. Take this as an FYI,
in case you get further, related reports.
With my setup (not with emacs -Q), at some point I got into a state
where there was a buffer associated with a window in a frame, and that
frame was neither visible anywhere nor iconified. It was not listed in
the Windows task bar, which lists each frame.
Yet Emacs thought that that the frame was visible (e.g. frame-visible-p
returned t). The buffer existed and was live, but it was displayed in
no visible or iconified window/frame anywhere.
Emacs functions such as raise-frame and select-frame-set-input-focus
returned normally, as if they worked, and the latter even deselected the
current frame (unhighlighted the title bar and borders) as if it had
selected another frame. But the target frame was not visible anywhere
(and not just off-screen, as determined by the Windows task-bar apps
list).
Here are some things I noted when in the debugger, in case it helps:
* display-buffer(#<buffer foo.el> t)
* pop-to-buffer(#<buffer foo.el> t nil)
* switch-to-buffer-other-frame(#<buffer foo.el>)
Then:
* display-buffer--maybe-same-window(#<buffer foo.el>
((inhibit-same-window . t)))
returned nil.
Then:
* get-buffer-window-list(#<buffer foo.el> nomini 0)
returned (#<window 50 on foo.el>)
Then:
* display-buffer-record-window(reuse #<window 50 on foo.el>
#<buffer foo.el>)
returned nil.
Then:
* window-parameter(#<window 50 on foo.el> quit-restore)
returned nil. Note that this window was visible nowhere.
Then:
* frame-visible-p(#<frame foo.el 047B6E00>)
returned t, even though the frame is not visible anywhere
and is not in the list of frames in the Windows task bar.
* window-frame(#<window 50 on foo.el>)
returned #<frame foo.el 047B6E00>.
* window--display-buffer-1(#<window 50 on foo.el>)
Then:
* raise-frame(#<frame foo.el 047B6E00>)
returned nil.
Then:
* select-window(#<window 50 on foo.el>)
returned #<window 50 on foo.el>.
So display-buffer-reuse-window, and hence display-buffer,
returned #<window 50 on foo.el>. And pop-to-buffer, and hence
switch-to-buffer-other-frame, returned buffer #<buffer foo.el>.
HTH in some way (ring a bell?). Sorry I don't have more info.
In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600) of 2011-11-21 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.6) --no-opt --cflags
-ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
-ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
-ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
-ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
-ID:/devel/emacs/libs/gnutls-2.10.1/include --ldflags
-LD:/devel/emacs/libs/gnutls-2.10.1/lib'
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10120
; Package
emacs
.
(Wed, 23 Nov 2011 20:14:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 10120 <at> debbugs.gnu.org (full text, mbox):
> Yet Emacs thought that that the frame was visible (e.g. frame-visible-p
> returned t). The buffer existed and was live, but it was displayed in
> no visible or iconified window/frame anywhere.
What does (frame-terminal <theframe>) return?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#10120
; Package
emacs
.
(Wed, 23 Nov 2011 20:34:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 10120 <at> debbugs.gnu.org (full text, mbox):
> > Yet Emacs thought that that the frame was visible (e.g.
> > frame-visible-p returned t). The buffer existed and was
> > live, but it was displayed in no visible or iconified
> > window/frame anywhere.
>
> What does (frame-terminal <theframe>) return?
I'm sorry, I no longer have the session. I tried to get some info by stepping
through the debugger, but didn't think of evaling `frame-terminal'. If I come
across this symptom again I'll find that out.
Reply sent
to
Glenn Morris <rgm <at> gnu.org>
:
You have taken responsibility.
(Fri, 08 Feb 2013 01:19:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Drew Adams" <drew.adams <at> oracle.com>
:
bug acknowledged by developer.
(Fri, 08 Feb 2013 01:19:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 10120-done <at> debbugs.gnu.org (full text, mbox):
Nothing can be done with this.
May as well open a new report if it ever recurs, rather than leaving
this open.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 08 Mar 2013 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 102 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.