From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Sun, 01 Nov 2020 20:35:54 +0200 Message-ID: <835z6ogc1h.fsf@gnu.org> References: <83wnzrwdy5.fsf@gnu.org> <20201021151945.GA19276@ACM> <20201021200438.GF19276@ACM> <83h7qmkzla.fsf@gnu.org> <20201030220917.GA17594@ACM> <83v9eq97sj.fsf@gnu.org> <20201031161422.GA5887@ACM> <83d00ygx9c.fsf@gnu.org> <20201031194419.GC5887@ACM> <834kmago8m.fsf@gnu.org> <20201031203914.GD5887@ACM> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30032"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 01 19:37:00 2020 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 1kZIDr-0007jG-Pq for ged-emacs-devel@m.gmane-mx.org; Sun, 01 Nov 2020 19:36:59 +0100 Original-Received: from localhost ([::1]:40070 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZIDq-0004zp-SW for ged-emacs-devel@m.gmane-mx.org; Sun, 01 Nov 2020 13:36:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33948) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZID3-0004Js-Rp for emacs-devel@gnu.org; Sun, 01 Nov 2020 13:36:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58875) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZID3-0003xf-DL; Sun, 01 Nov 2020 13:36:09 -0500 Original-Received: from [176.228.60.248] (port=3062 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kZICz-0005rI-Fr; Sun, 01 Nov 2020 13:36:08 -0500 In-Reply-To: <20201031203914.GD5887@ACM> (message from Alan Mackenzie on Sat, 31 Oct 2020 20:39:14 +0000) 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:258605 Archived-At: > Date: Sat, 31 Oct 2020 20:39:14 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > > How about emptying mini-windows which don't have live minibuffers on > > > them? This could be tested by Fminibufferp (b, Qt). In practice, when > > > minibuffer-follows-selected-frame this would empty all mini-windows but > > > the current one, and when !m-f-s-f it would leave intact the mini-windows > > > we want to be left intact. > > > let me turn the table and ask why this hunk is needed? What doesn't > > work right if this code is left in place? > > Without that hunk (i.e. with the emptying-out code): > (i) emacs -Q > (ii) M-: (setq minibuffer-follows-selected-frame nil) > (iii) C-x 5 2 ; giving two frames. > (iv) C-x b ; leaving a minibuffer open. > (v) C-x 5 o ; move to other frame. > > (vi) C-r in ; start an isearch. > (vii) C-x 8 RET ; intending on inserting a non-keyboard character. > > At this point, the mini-window in Frame 1 is emptied. This is bad. But the same happens with the current master. So this is no worse than what we have today. > By contrast, the same sequence of operations without (ii) (with an extra > step: > > (v).5 C-x o ; move to the ordinary window. > > ), the first minibuffer is "protected" on Frame 2 underneath the C-x 8 > RET minibuffer. So, when the isearch is finished, the "Switch to > buffer" minibuffer appears again, and is active. Is this with or without removing the code which empties all the other minibuffers?