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: Fri, 19 Mar 2021 14:33:20 +0200 Message-ID: <83mtuze31r.fsf@gnu.org> References: <875z1tfn0p.fsf@miha-pc> <83czvxd079.fsf@gnu.org> <83blbhcz41.fsf@gnu.org> <83sg4sbs6w.fsf@gnu.org> <694e12db-a19c-31f8-077c-62d32b640eb9@gmx.at> <83o8fgfgjn.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="708"; 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 Fri Mar 19 13:34:59 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 1lNELD-000Abb-BE for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Mar 2021 13:34:59 +0100 Original-Received: from localhost ([::1]:34784 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNELC-0003QB-BN for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Mar 2021 08:34:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNEJh-0002W1-QW for emacs-devel@gnu.org; Fri, 19 Mar 2021 08:33:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33291) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNEJe-0005sG-Tw; Fri, 19 Mar 2021 08:33:23 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4960 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lNEJc-0006Py-Tt; Fri, 19 Mar 2021 08:33:21 -0400 In-Reply-To: (message from Alan Mackenzie on Fri, 19 Mar 2021 11:40:52 +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:266599 Archived-At: > Date: Fri, 19 Mar 2021 11:40:52 +0000 > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no, > emacs-devel@gnu.org > From: Alan Mackenzie > > > > > What about answering questions about unsaved buffers, running processes > > > > ... in such a situation? I never use emacsclient so I have no idea how > > > > this should behave in practice. > > > > I don't use emacsclient either. But questions about unsaved buffers > > > seem to prevent Emacs terminating until they get answered. The same for > > > running processes (at least, for gdb). > > > Are we shutting down Emacs, or are we returning to a headless daemon > > state? > > Returning to a headless daemon state. Then I think there's no need to ask those questions at all. Emacs is not going away, so it's okay to leave unsaved edits in the session that continues to run. > When I now try Miha's recipe: > (In last frame of emacsclient:) > M-: (run-at-time 10 nil #'make-frame '((window-system . x))) > C-x C-f foo > Close the frame by clicking on its close button > > > , the new frame comes up _with_ the minibuffer visible. I don't > understand how the mini window survived with its contents, and it > worries me. Why does it worry you? You've asked Emacs to create a frame, and a frame by default has a mini-window. Right? > Could it be that the last frame isn't actually deleted from the Emacs > daemon when clicking on its close button? I think indeed that's what happens, because otherwise clicking there would have shut down Emacs -- which it doesn't in the daemon case. > This is the sort of thing I would like to be able to read about in the > Elisp manual You expect the ELisp manual to describe the internals to this detail? That's stuff for comments in the code (adding which will be very welcome), not for the ELisp reference. > along with basic questions like "How can one test whether one is in > an emacsclient session rather than an ordinary Emacs?". This seems to be a matter of improving indexing: see the variable mode-line-client and how it is computed.