From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Miha =?utf-8?B?UmlodGFyxaFpxI0=?= Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Sun, 14 Mar 2021 22:23:02 +0100 Message-ID: <875z1tfn0p.fsf@miha-pc> References: <87wnvkixrv.fsf@miha-pc> <874kinakv2.fsf@miha-pc> <87sg6690vc.fsf@miha-pc> <87pn02ojwu.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="13046"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 14 22:22:35 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 1lLYC3-0003HA-8u for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Mar 2021 22:22:35 +0100 Original-Received: from localhost ([::1]:53134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lLYC2-0004jM-2v for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Mar 2021 17:22:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lLY9L-00046J-Hq for emacs-devel@gnu.org; Sun, 14 Mar 2021 17:19:47 -0400 Original-Received: from chiru.no ([142.4.209.132]:50888) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1lLY9K-0004TR-2H for emacs-devel@gnu.org; Sun, 14 Mar 2021 17:19:47 -0400 Original-Received: from localhost (BSN-77-156-43.static.siol.net [193.77.156.43]) by chiru.no (Postfix) with ESMTPSA id B849F128001B; Sun, 14 Mar 2021 21:19:43 +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: -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_NONE=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:266466 Archived-At: Alan Mackenzie writes: > Hello, Jakanakaevangeli, > > On Sat, Mar 13, 2021 at 21:53:05 +0100, jakanakaevangeli wrote: > > [ .... ] > >> 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. > > I think one of the two previous changes fixed this. Sorry, this still doesn't seem to be fixed. Just in case I wasn't clear enough, I'll try to reiterate. When a frame is closed, it's active minibuffer should now be moved to another frame. What I wanted to test then was, what happens if we have only a single frame with a minibuffer and we decide to close it, which is possible with emacs daemon. Immediately, there will be no frames left for the minibuffer to take refuge in and this seems to cause some problems. And two new regressions. These require minibuffer-follows-selected-frame to be set to t. 1) C-x C-f on frame A select frame B select frame A Minibuffer is moved to B, but not back to A. 2) Have two frames open open a minibuffer on a frame close this frame The other frame does have the miniwindow selected, but the minibuffer isn't shown in it. Best.