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: Wed, 14 Oct 2020 20:05:36 +0300 Message-ID: <838sc8zqjj.fsf@gnu.org> References: <20201013190255.GA8896@ACM> <838sca0w7k.fsf@gnu.org> <20201013195103.GB8896@ACM> <20201013204408.GC8896@ACM> <831ri027vz.fsf@gnu.org> <20201014160240.GA7651@ACM> <83d01kzswk.fsf@gnu.org> <20201014163534.GB7651@ACM> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23631"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ghe@sdf.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 14 19:11: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 1kSkIl-00061p-T0 for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 19:10:59 +0200 Original-Received: from localhost ([::1]:57550 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSkIk-0003E9-Nx for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 13:10:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSkDR-0006I8-TE for emacs-devel@gnu.org; Wed, 14 Oct 2020 13:05:35 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33133) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSkDP-0001B0-Tl; Wed, 14 Oct 2020 13:05:27 -0400 Original-Received: from [176.228.60.248] (port=4845 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kSkDO-0006uZ-Je; Wed, 14 Oct 2020 13:05:27 -0400 In-Reply-To: <20201014163534.GB7651@ACM> (message from Alan Mackenzie on Wed, 14 Oct 2020 16:35:34 +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:257662 Archived-At: > Date: Wed, 14 Oct 2020 16:35:34 +0000 > Cc: ghe@sdf.org, emacs-devel@gnu.org > From: Alan Mackenzie > > > To me, consistent behavior would be to switch to the mini-window of > > the selected frame. > > I'm not quite sure what a mini-window is. Does it mean the window within > which the minibuffer is displayed? As in max-mini-window-height? The mini-window is the small window at the bottom of the frame which is used to display the echo area and the minibuffer. > My apologies for being unclear. I was thinking about what happens after > the Isearch is over. Currently the minibuffer is pulled in if the > Isearch has used the minibuffer for any reason. With my patch, this > would never happen after an Isearch. > > What I meant was that with the "always" variation, after an Isearch, an > open minibuffer would always be pulled over from another frame. Would you please describe the recipe to try, and then describe how you would like to change the current behavior in that recipe? I feel that I don't really understand what you are trying to say (e.g., what does "minibuffer is pulled in" mean?). Thanks.