From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: What are invisible frames for? Date: Thu, 22 Apr 2021 10:09:10 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39646"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 22 12:09:50 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZWHN-000A62-8v for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Apr 2021 12:09:49 +0200 Original-Received: from localhost ([::1]:38002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZWHM-0007tk-A2 for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Apr 2021 06:09:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49506) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZWGr-0007UB-1H for emacs-devel@gnu.org; Thu, 22 Apr 2021 06:09:17 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:49014 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lZWGo-0007Vp-S9 for emacs-devel@gnu.org; Thu, 22 Apr 2021 06:09:16 -0400 Original-Received: (qmail 89446 invoked by uid 3782); 22 Apr 2021 10:09:10 -0000 Original-Received: from acm.muc.de (p4fe15bfe.dip0.t-ipconnect.de [79.225.91.254]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 22 Apr 2021 12:09:10 +0200 Original-Received: (qmail 13555 invoked by uid 1000); 22 Apr 2021 10:09:10 -0000 Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268271 Archived-At: Hello, Emacs. In src/frame.c, the notion of an @dfn{invisible frame} is implemented. On a GUI, when a frame is in this invisible state, it appears to be completely inaccessible to the user - it doesn't appear anywhere on the GUI, there appear to be no commands to access it, and so on. Only a Lisp form can do anything with it, like making it visible again. What is this facility used for? There're uses in dframe.el, and there's something in cl-extra.el saying it's "support for setf". There aren't really any uses in the C files - just one call in minibuf.c when something else has set up an option for it. So what is this thing for? The reason I ask is that making frames invisible (or even iconified) affects any minibuffers on those frames. The current handling, which is old, moves the minibuffers onto another frame. This conflicts with the meaning of the (newish) variable minibuffer-follows-selected-frame when its value isn't t. In particular, when m-f-s-f is nil, minibuffers are defined to stay on the frame they were first created on. So, to determine how these MBs should be handled, it would be very useful to understand what invisible frames are used for. This has relevance for bug #47766. Thanks in advance! -- Alan Mackenzie (Nuremberg, Germany).