[Top][All Lists]

[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: Sat, 20 Jul 2013 16:54:05 +0200

On Sat, Jul 20, 2013 at 3:39 PM, Eli Zaretskii <address@hidden> wrote:

>> emacs -Q
>> M-: (setq *f* (make-frame '((visibility . nil)))) <RET>
>> M-: (frame-visible-p *f*) <RET>
>>  => t
> In your example, it said "nil", not "t":
>   ELISP> (progn (setq *f* (make-frame '((visibility . icon))))
>   (frame-visible-p *f*))
>   nil
> And that's what I get after the change mentioned previously.

Allow me to recapitulate. Without your patch (that I haven't yet tested):

(1) M-: (progn (setq *f* (make-frame '((visibility . X))))
(frame-visible-p *f*)) <RET>
(2) M-: (frame-visible-p *f*) <RET>

 X      (1)   (2)
------ ----- ------
 t       t     t
 nil    nil    t
 icon   nil   icon

I think both the (1) and (2) columns show bugs.

In column (1), if t is the right value for visibility = t, because the
frame is already shown, and nil is the right value for visibility .
nil, because it is invisible, then the answer for visibility . icon
should be icon, because the frame is already iconified (and so,

For column (2), the value t for visibility . nil is a bug, because the
frame is invisible.

> Because frame-visible-p makes no sense as long as the frame was not
> displayed.  (In what sense is an un-displayed frame "visible"?)

"Frame visibility" conflates two three things: whether and how the
user sees the frame, what does elisp think about the frame status, and
what the frame parameter of the frame says about its status. We use
frame-visible-p for the first two queries, or rather, for the second
one hoping that it matches the first one. If you disagree and think
that frame-visible-p should only answer the first query, then we need
a way to ask the second one, because sometimes you have to create a
frame and do things with it long before it is displayed ("long" in the
sense that many things happen between it being created and being
displayed). That's not a theoretical exercise, that's a bug that's
bitten me with desktop-restore-frames.


reply via email to

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