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: Thu, 18 Mar 2021 11:27:18 +0000 Message-ID: References: <87sg6690vc.fsf@miha-pc> <87pn02ojwu.fsf@miha-pc> <875z1tfn0p.fsf@miha-pc> <83czvxd079.fsf@gnu.org> <83blbhcz41.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="33830"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 Thu Mar 18 12:29:11 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 1lMqpx-0008fb-I0 for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Mar 2021 12:29:09 +0100 Original-Received: from localhost ([::1]:42994 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lMqpw-0000cW-IB for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Mar 2021 07:29:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMqoF-00081A-JS for emacs-devel@gnu.org; Thu, 18 Mar 2021 07:27:23 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:22421 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lMqoD-0000Qj-CF for emacs-devel@gnu.org; Thu, 18 Mar 2021 07:27:23 -0400 Original-Received: (qmail 61216 invoked by uid 3782); 18 Mar 2021 11:27:18 -0000 Original-Received: from acm.muc.de (p4fe15597.dip0.t-ipconnect.de [79.225.85.151]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 18 Mar 2021 12:27:18 +0100 Original-Received: (qmail 19491 invoked by uid 1000); 18 Mar 2021 11:27:18 -0000 Content-Disposition: inline In-Reply-To: <83blbhcz41.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:266558 Archived-At: Hello, Eli. On Wed, Mar 17, 2021 at 22:19:10 +0200, Eli Zaretskii wrote: > > Date: Wed, 17 Mar 2021 21:55:38 +0200 > > From: Eli Zaretskii > > Cc: monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no, emacs-devel@gnu.org > > > This could be difficult to fix. I don't think that clicking on the last > > > frame's close button goes through `delete-frame' - it just closes the > > > program, whether that's emacs or emacsclient. > > I'm not sure I understand completely what you say here, but clicking > > on the frame's close button does invoke delete-frame, see the handling > > of DELETE_FRAME_EVENT in keyboard.c. > And if you are talking about the last live frame of an Emacs session, > then look at handle-delete-frame, which is called when you click that > close button: it will call save-buffers-kill-emacs (which has a hook) > and then kill-emacs (which also has a hook). Thank you, that is very helpful. I was indeed talking about the last live frame, specifically in an emacsclient session when the Emacs daemon is running. The problem that Miha highlighted is that when there is an open minibuffer when that last frame is deleted, that open minibuffer remains in existence, fouling up the next emacsclient session. 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. Incidentally, there doesn't seem to be anything in the Elisp manual about the handling of Emacs daemon sessions. -- Alan Mackenzie (Nuremberg, Germany).