From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: jakanakaevangeli Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Sat, 13 Mar 2021 21:53:05 +0100 Message-ID: <87pn02ojwu.fsf@miha-pc> References: <87wnvkixrv.fsf@miha-pc> <874kinakv2.fsf@miha-pc> <87sg6690vc.fsf@miha-pc> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22621"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 13 21:52:56 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 1lLBFn-0005mP-Vy for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Mar 2021 21:52:55 +0100 Original-Received: from localhost ([::1]:35380 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lLBFm-0004fn-St for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Mar 2021 15:52:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36436) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lLBCv-000420-8F for emacs-devel@gnu.org; Sat, 13 Mar 2021 15:49:57 -0500 Original-Received: from chiru.no ([142.4.209.132]:34458) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1lLBCt-0000il-NS for emacs-devel@gnu.org; Sat, 13 Mar 2021 15:49:57 -0500 Original-Received: from localhost (BSN-77-156-43.static.siol.net [193.77.156.43]) by chiru.no (Postfix) with ESMTPSA id 9335A128001B; Sat, 13 Mar 2021 20:49:53 +0000 (UTC) In-Reply-To: Received-SPF: none client-ip=142.4.209.132; envelope-from=jakanakaevangeli@chiru.no; helo=chiru.no X-Spam_score_int: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no 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:266444 Archived-At: Alan Mackenzie writes: > Hello, Stefan and jakanakaevangeli. > > 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. > > Just a quick recapitulation of the problem: when > minibuffer-follows-selected-frame is nil, and > enable-recursive-minibuffers t, it is possible to have several open > minibuffers on several frames. If one of these frames is deleted, its > minibuffers continue to exist, but are wholly inaccessible - the only > thing to do with them is to abort them, e.g. with C-]. This is > suboptimal. > > The patch below tries to solve this by, when such a frame gets deleted, > "zipping" its minibuffers into those of another frame. The idea behind > the patch is to use the mini-window's w->prev_buffers component to hold > the list of its minibuffers. This mini-window component was unused by > the rest of Emacs, apart from accidentally by > window--before-delete-windows, which I have now amended. > > I would be grateful indeed if either of you (or indeed, anybody else), > would apply the patch and try it out, or indeed comment on it. Thanks! Great! I tested it and there still seem to be a few ways one can end up with invisible active minibuffers, all of them with minibuffer-follows-selected-frame set to nil: 1) C-x C-f on frame A C-x C-f on frame B select frame A and press C-] (abort-recursive-edit) This does quit only the inner minibuffer as expected but it hides the outer one for some reason. This also seems to be a regression of this patch, the minibuffer isn't hidden without this patch applied. 2) (Might depend on your window manager, I'm not sure) Open frames A, B, and C C-x C-f on frame A C-x b on frame B Close frame A Both of the minibuffers are now moved to frame C and the outer C-x C-f is shown in the mini-window, which is kind of annoying. If we now select frame C and press C-], the same problem as in 1) occurs. 3) In emacs daemon, evaluate (run-at-time 5 nil #'make-frame '((window-system . x))) and then open a minibuffer and close the last frame. When a new frame appears, the same problem as in 1) occurs. Hope this helps.