[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14841: Frames created invisible have their visibility parameter set
From: |
Juanma Barranquero |
Subject: |
bug#14841: Frames created invisible have their visibility parameter set to t |
Date: |
Thu, 11 Jul 2013 17:14:19 +0200 |
Package: emacs
Version: 20.7.3
X-Debbugs-CC: eliz@gnu.org
This is a very old bug, I see the same behavior since 20.7.3 (the
older binary I have) but it is likely there since the redisplay
rewriting in 20.1.
I don't know if this is Windows related. Could someone please test it
in a POSIX build?
Anyway, the bug: frames made invisible with set-frame-parameter,
modify-frame-parameters or make-frame-invisible have their visibility
parameter really set to nil. However, frames created already invisible
with (make-frame '((visibility . nil)), which *are* invisible, have
their visibility parameter set to t as soon as there's some redisplay.
ELISP> (setq f1 (make-frame '((visibility))))
#<frame emacs@ODIEONE 037b77e0>
ELISP> (frame-parameter f1 'visibility)
t
ELISP> (mapcar #'frame-visible-p (frame-list))
(t t)
ELISP> (make-frame-invisible f1)
nil
ELISP> (frame-parameter f1 'visibility)
nil
ELISP> (mapcar #'frame-visible-p (frame-list))
(nil t)
ELISP> (setq f2 (make-frame))
#<frame emacs@ODIEONE 0518b7d8>
ELISP> (set-frame-parameter f2 'visibility nil)
nil
ELISP> (frame-parameter f2 'visibility)
nil
ELISP> (mapcar #'frame-visible-p (frame-list))
(nil nil t)
ELISP> (let ((f3 (make-frame '((visibility)))))
(frame-parameter f3 'visibility))
nil
ELISP> (mapcar #'frame-visible-p (frame-list))
(t nil nil t)
This could be related to this comment in frame.h
On ttys and on Windows NT/9X, to avoid wasting effort updating
visible frames that are actually completely obscured by other
windows on the display, we bend the meaning of visible slightly:
if equal to 2, then the frame is obscured - we still consider
it to be "visible" as seen from lisp, but we don't bother
updating it. We must take care to garbage the frame when it
ceases to be obscured though. See SET_FRAME_VISIBLE below. */
unsigned visible : 2;
which would mean it is a Windows-specific display bug.
This affects the frame-restore functionality I'm testing, because many
frames are "restored" via (make-frame SOME-BIG-PARAMETER-LIST). I can
work around the bug by treating visibility specially, of course, but
still, it is a bug, because the affected frames are not "obscured",
they are invisible.
- bug#14841: Frames created invisible have their visibility parameter set to t,
Juanma Barranquero <=
- bug#14841: Frames created invisible have their visibility parameter set to t, Eli Zaretskii, 2013/07/11
- bug#14841: Frames created invisible have their visibility parameter set to t, Juanma Barranquero, 2013/07/11
- bug#14841: Frames created invisible have their visibility parameter set to t, Eli Zaretskii, 2013/07/11
- bug#14841: Frames created invisible have their visibility parameter set to t, Juanma Barranquero, 2013/07/11
- bug#14841: Frames created invisible have their visibility parameter set to t, Eli Zaretskii, 2013/07/14
- bug#14841: Frames created invisible have their visibility parameter set to t, Juanma Barranquero, 2013/07/14
- bug#14841: Frames created invisible have their visibility parameter set to t, Juanma Barranquero, 2013/07/19
- bug#14841: Frames created invisible have their visibility parameter set to t, Eli Zaretskii, 2013/07/20
- bug#14841: Frames created invisible have their visibility parameter set to t, Juanma Barranquero, 2013/07/20
- bug#14841: Frames created invisible have their visibility parameter set to t, Eli Zaretskii, 2013/07/20