bug#14841: Frames created invisible have their visibility parameter set to t

[Juanma Barranquero <lekktu@gmail.com>]

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.