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: Tue, 13 Oct 2020 19:51:03 +0000 Message-ID: <20201013195103.GB8896@ACM> References: <20201013190255.GA8896@ACM> <838sca0w7k.fsf@gnu.org> 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="30731"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 13 21:52:46 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 1kSQLk-0007sY-Kz for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 21:52:44 +0200 Original-Received: from localhost ([::1]:43918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSQLj-0007S8-KI for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 15:52:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45576) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSQKB-0006Lx-VM for emacs-devel@gnu.org; Tue, 13 Oct 2020 15:51:07 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:53885 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kSQK9-0003cz-Rr for emacs-devel@gnu.org; Tue, 13 Oct 2020 15:51:07 -0400 Original-Received: (qmail 37883 invoked by uid 3782); 13 Oct 2020 19:51:03 -0000 Original-Received: from acm.muc.de (p4fe1592a.dip0.t-ipconnect.de [79.225.89.42]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Tue, 13 Oct 2020 21:51:03 +0200 Original-Received: (qmail 9668 invoked by uid 1000); 13 Oct 2020 19:51:03 -0000 Content-Disposition: inline In-Reply-To: <838sca0w7k.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) 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-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/13 15:02:56 X-ACL-Warn: Detected OS = FreeBSD 9.x or newer [fuzzy] 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:257572 Archived-At: Hello, Eli. On Tue, Oct 13, 2020 at 22:20:15 +0300, Eli Zaretskii wrote: > > Date: Tue, 13 Oct 2020 19:02:55 +0000 > > From: Alan Mackenzie > > Seeing as how a minibuffer often has a strong association with its frame > > (e.g., C-x C-f opens a buffer in the same frame it was invoked from), > > this shifting of minibuffers from one frame to another is confusing. > Is it? It is (or was) to me. Seeing it for the first time, a user wouldn't know whether the C-x C-f would open the buffer in the current frame or the one she issued the command from. > It makes sure the minibuffer is on the selected frame, which is > natural in many/most use cases. It only does this sometimes. If the command using the minibuffer is given on frame F1, and the selected frame becomes F2, the minibuffer sometimes moves, sometimes doesn't, depending on what the user does. For example, C-s in F2 doesn't usually move the minibuffer, but it will if you use C-x 8 RET. This is inconsistent. > Forcing the user to go back to a non-selected frame _is_ IMO confusing > and inconvenient, at least in the usual cases. I don't find it so. The frame you complete a minibuffer command in should be the one you started it from. IMNSHO. -- Alan Mackenzie (Nuremberg, Germany).