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: Re: Stop frames stealing eachothers' minibuffers! Date: Sat, 20 Mar 2021 12:24:55 +0000 Message-ID: References: <83sg4sbs6w.fsf@gnu.org> <694e12db-a19c-31f8-077c-62d32b640eb9@gmx.at> <83o8fgfgjn.fsf@gnu.org> <83mtuze31r.fsf@gnu.org> <838s6jdthq.fsf@gnu.org> <83im5mcd7i.fsf@gnu.org> 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="34862"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 20 13:26:22 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 1lNagP-00090G-V3 for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Mar 2021 13:26:21 +0100 Original-Received: from localhost ([::1]:49746 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNagO-0005tp-WC for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Mar 2021 08:26:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48842) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNafA-0005O9-Rr for emacs-devel@gnu.org; Sat, 20 Mar 2021 08:25:04 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:46944 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lNaf7-0004I2-5i for emacs-devel@gnu.org; Sat, 20 Mar 2021 08:25:04 -0400 Original-Received: (qmail 63861 invoked by uid 3782); 20 Mar 2021 12:24:56 -0000 Original-Received: from acm.muc.de (p2e5d55b2.dip0.t-ipconnect.de [46.93.85.178]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 20 Mar 2021 13:24:56 +0100 Original-Received: (qmail 6171 invoked by uid 1000); 20 Mar 2021 12:24:55 -0000 Content-Disposition: inline In-Reply-To: <83im5mcd7i.fsf@gnu.org> 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:266644 Archived-At: Hello, Eli. On Sat, Mar 20, 2021 at 12:49:05 +0200, Eli Zaretskii wrote: > > 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. Apologies, I was wrong. On the first emacsclient call, a second frame gets created. The initial frame is marked in some way so that, e.g., C-x 5 o doesn't see it. > > 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. So, when a new frame is created (possibly with emacsclient), and there are now exactly two frames, we want to copy any minibuffers from the other frame to the new one when that other frame is the initial frame. I still can't find a way of identifying the initial frame for sure - it lacks a 'display frame parameter, but so do ordinary frames on a tty. It lacks a 'client frame parameter, but so do ordinary frames when Emacs is started normally and M-x server-start invoked. Would it, perhaps, be useful to add another frame parameter 'initial-frame to identify this frame? [ .... ] -- Alan Mackenzie (Nuremberg, Germany).