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, 12 Feb 2021 09:48:18 +0000 Message-ID: References: <87wnvkixrv.fsf@miha-pc> <874kinakv2.fsf@miha-pc> <87sg6690vc.fsf@miha-pc> 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="28473"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jakanakaevangeli , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 12 10:49:24 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 1lAV4m-0007JM-3U for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Feb 2021 10:49:24 +0100 Original-Received: from localhost ([::1]:45364 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAV4l-0004cV-5K for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Feb 2021 04:49:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57670) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAV3q-00049e-2r for emacs-devel@gnu.org; Fri, 12 Feb 2021 04:48:26 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:25696 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lAV3o-0007cf-3K for emacs-devel@gnu.org; Fri, 12 Feb 2021 04:48:25 -0500 Original-Received: (qmail 17105 invoked by uid 3782); 12 Feb 2021 09:48:19 -0000 Original-Received: from acm.muc.de (p4fe15b4a.dip0.t-ipconnect.de [79.225.91.74]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 12 Feb 2021 10:48:19 +0100 Original-Received: (qmail 3917 invoked by uid 1000); 12 Feb 2021 09:48:18 -0000 Content-Disposition: inline In-Reply-To: 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:264480 Archived-At: Hello, Stefan. Thanks for still reading this old thread! On Thu, Feb 11, 2021 at 09:29:44 -0500, Stefan Monnier wrote: > > This is more involved. What do we want to happen when a frame with open > > minibuffers is deleted? I would say that these minibuffers should, > > except in the (eq minibuffer-follows-selected-frame t) case, be aborted, > > together with any others in other frames whose nesting level makes this > > necessary. > I vote for moving those minibuffers elsewhere (anywhere else is fine by > me, really). I assume it's no more complicated code-wise, and it should > suffer less from the risk of losing information. Thinking about it, you are right. Deleting frames doesn't abort any other buffers, so why should minibuffers suffer? The code is going to be tedious and moderately difficult to write either way. So I think on deleting a frame, any minibuffers in it should get pushed onto the previous frame. > Stefan -- Alan Mackenzie (Nuremberg, Germany).