From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Sat, 20 Mar 2021 12:49:05 +0200 Message-ID: <83im5mcd7i.fsf@gnu.org> References: <83blbhcz41.fsf@gnu.org> <83sg4sbs6w.fsf@gnu.org> <694e12db-a19c-31f8-077c-62d32b640eb9@gmx.at> <83o8fgfgjn.fsf@gnu.org> <83mtuze31r.fsf@gnu.org> <838s6jdthq.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27449"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 20 11:50:19 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 1lNZBS-00072e-PU for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Mar 2021 11:50:18 +0100 Original-Received: from localhost ([::1]:54072 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNZBR-0006JZ-Qv for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Mar 2021 06:50:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35910) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNZAM-0005JY-25 for emacs-devel@gnu.org; Sat, 20 Mar 2021 06:49:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52285) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNZAK-0007K6-12; Sat, 20 Mar 2021 06:49:08 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3850 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lNZAJ-0002CE-1B; Sat, 20 Mar 2021 06:49:07 -0400 In-Reply-To: (message from Alan Mackenzie on Sat, 20 Mar 2021 10:28:26 +0000) 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:266639 Archived-At: > Date: Sat, 20 Mar 2021 10:28:26 +0000 > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no, > emacs-devel@gnu.org > From: Alan Mackenzie > > > I think this is the initial frame that exists in every Emacs session > > when it starts, except that in the daemon we don't delete it. It's a > > non-GUI frame which exists just to keep code that expects some frame > > to exist happy. > > This initial frame gets used as a normal frame when one calls > > $ emacsclient foo > > for the first time. Are you sure? ISTR that we create a new frame on the terminal from which emacsclient was invoked. The initial frame is never used except at startup and when the daemon should do something while it has no clients. > It stays in use until one clicks on its close > button (I think this is actually the close button of the containing > xterm). When a new GUI frame is brought up by > > M-: (run-at-time 10 nil #'make-frame '((window-system . x))) > > , the initial frame may or may not have been "closed" by clicking its > close button. I think you're telling me that it's not possible to > distinguish these two cases. If so, that's surely a defect in Emacs. No, I'm saying that the initial frame is never deleted. At least that's my recollection. > > We don't have a means of knowing whether a TTY frame is displayed, it > > conceptually always is. > > Perhaps we should create some means of knowing this? Maybe in > handle-delete-frame, where Emacs has determined there is only one frame > left, before calling save-buffers-kill-emacs we could mark the last > frame's f->visible to "not visible". You mean, for a frame that is about to be deleted anyway? what purpose would that serve?