From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.bugs Subject: bug#14841: Frames created invisible have their visibility parameter set to t Date: Sat, 20 Jul 2013 16:54:05 +0200 Message-ID: References: <83a9ltun54.fsf@gnu.org> <837ggxukjt.fsf@gnu.org> <83hafx3wzz.fsf@gnu.org> <83txjpxue1.fsf@gnu.org> <83siz9xsdq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1374332113 11779 80.91.229.3 (20 Jul 2013 14:55:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Jul 2013 14:55:13 +0000 (UTC) Cc: 14841@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 20 16:55:10 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V0YYv-0003Ce-M2 for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Jul 2013 16:55:09 +0200 Original-Received: from localhost ([::1]:55063 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0YYv-0007xE-5s for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Jul 2013 10:55:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0YYq-0007vo-JG for bug-gnu-emacs@gnu.org; Sat, 20 Jul 2013 10:55:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0YYp-0004TU-Bp for bug-gnu-emacs@gnu.org; Sat, 20 Jul 2013 10:55:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0YYp-0004Sz-7p for bug-gnu-emacs@gnu.org; Sat, 20 Jul 2013 10:55:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1V0YYo-0005k4-N0 for bug-gnu-emacs@gnu.org; Sat, 20 Jul 2013 10:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juanma Barranquero Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Jul 2013 14:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14841 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: Original-Received: via spool by 14841-submit@debbugs.gnu.org id=B14841.137433209522045 (code B ref 14841); Sat, 20 Jul 2013 14:55:02 +0000 Original-Received: (at 14841) by debbugs.gnu.org; 20 Jul 2013 14:54:55 +0000 Original-Received: from localhost ([127.0.0.1]:39675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V0YYg-0005jP-Lx for submit@debbugs.gnu.org; Sat, 20 Jul 2013 10:54:55 -0400 Original-Received: from mail-ee0-f46.google.com ([74.125.83.46]:61878) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V0YYd-0005ir-Qi for 14841@debbugs.gnu.org; Sat, 20 Jul 2013 10:54:52 -0400 Original-Received: by mail-ee0-f46.google.com with SMTP id d41so2906756eek.5 for <14841@debbugs.gnu.org>; Sat, 20 Jul 2013 07:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kZ5kPYBNcBp9lPzmzIX41QJhjq7Gl1dSUsLV6pkbIs4=; b=DI6uQTFAb8sxPSP9Khyd4b1U/ISwLEKsKV1agoX31rIJQJAlspm8rxQB+Uq2iW+iXC kHmHyZYN7F/JJGQms/Fqev5kucIMLsdXYVfwusbQGq0GO+MXfyugwY3oFkUtmgbt2AsS r+TLwvX2TCNq+Dv+o6pXlc4/O1K0jtF/pTXqmNsw/FtmMlyFaZcyDMzGekIkNtNdzlHz tE4UO1Wt62uoZm2O7ABAmtXoZ8s1tBksoFZpeugyvsWjjxP0G10k4yIfcRkKdhqxSUOr oCMKL2fT6aLE6jHkWkbErtBNAGJSYATlW2oD1taAOaWigTsOGA1icRMCs8D/mDIOgnAS N1tg== X-Received: by 10.14.219.6 with SMTP id l6mr19682312eep.152.1374332085527; Sat, 20 Jul 2013 07:54:45 -0700 (PDT) Original-Received: by 10.14.142.4 with HTTP; Sat, 20 Jul 2013 07:54:05 -0700 (PDT) In-Reply-To: <83siz9xsdq.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:76531 Archived-At: On Sat, Jul 20, 2013 at 3:39 PM, Eli Zaretskii wrote: >> emacs -Q >> M-: (setq *f* (make-frame '((visibility . nil)))) >> M-: (frame-visible-p *f*) >> => 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*)) (2) M-: (frame-visible-p *f*) 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, "visible"). 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. J