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: Fri, 19 Mar 2021 11:40:52 +0000 Message-ID: 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> 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="37931"; 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 Fri Mar 19 12:49:58 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 1lNDdd-0009jq-Qb for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Mar 2021 12:49:57 +0100 Original-Received: from localhost ([::1]:54700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lNDdc-0002PD-Io for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Mar 2021 07:49:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37774) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lNDUw-0004Ua-Mx for emacs-devel@gnu.org; Fri, 19 Mar 2021 07:40:58 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:61630 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lNDUt-0001h4-UR for emacs-devel@gnu.org; Fri, 19 Mar 2021 07:40:58 -0400 Original-Received: (qmail 6832 invoked by uid 3782); 19 Mar 2021 11:40:53 -0000 Original-Received: from acm.muc.de (p4fe15c9a.dip0.t-ipconnect.de [79.225.92.154]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 19 Mar 2021 12:40:52 +0100 Original-Received: (qmail 4970 invoked by uid 1000); 19 Mar 2021 11:40:52 -0000 Content-Disposition: inline In-Reply-To: <83o8fgfgjn.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:266596 Archived-At: Hello, Eli. On Thu, Mar 18, 2021 at 20:44:12 +0200, Eli Zaretskii wrote: > > Date: Thu, 18 Mar 2021 16:58:25 +0000 > > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, > > jakanakaevangeli@chiru.no, emacs-devel@gnu.org > > From: Alan Mackenzie > > > >> Maybe such open minibuffers should just be aborted (along with any other > > > >> recursive edits) when the last frame gets deleted. This would be > > > >> simpler to code than preserving those minibuffers somewhere, and > > > >> restoring them at the next emacsclient session. Aborting them also > > > >> seems more natural, since their contents are unlikely to have any > > > >> relevance to the next emacsclient session. > > > > Martin, can you comment on this, please? > > > 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. > If the former, we need to ask all those questions before we shut down > Emacs. Why is it a problem to ask them? Sorry, I didn't mean to imply these things were problems; it was just an observation, comparing the question about unsaved buffers with the lack of a question on open minibuffers. In the following, I'm using my not yet committed version of minibuf.c, etc.: 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. The minibuffers are stored in the frames' ->minibuffer_window components, as well as existing as buffers in their own right. When the last frame is deleted, I would expect the MB to survive, but NOT to be put back into the mini window of the newly created frame. Could it be that the last frame isn't actually deleted from the Emacs daemon when clicking on its close button? Merely that the emacsclient program is closed, leaving its window inactive/invisible/whatever? In fact running M-: (frame-list) shows two frames, one of which is called " *Minibuf-1*", though it isn't displayed in X-Windows. This is the sort of thing I would like to be able to read about in the Elisp manual, along with basic questions like "How can one test whether one is in an emacsclient session rather than an ordinary Emacs?". -- Alan Mackenzie (Nuremberg, Germany).