From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Fri, 27 Nov 2020 12:03:38 +0000 Message-ID: References: <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> <20201125215450.GC8228@ACM> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11171"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Andrii Kolomoiets , emacs-devel@gnu.org, martin rudalics , enometh@meer.net, Stefan Monnier , Eli Zaretskii To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 27 13:04:54 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 1kicUf-0002m5-PE for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 13:04:53 +0100 Original-Received: from localhost ([::1]:35132 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kicUe-00061s-PK for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 07:04:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kicTn-0005Cl-4U for emacs-devel@gnu.org; Fri, 27 Nov 2020 07:03:59 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:55692) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kicTk-00033v-SX; Fri, 27 Nov 2020 07:03:58 -0500 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 0ARC3fU5026298 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 27 Nov 2020 12:03:41 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0ARC3e8g006552; Fri, 27 Nov 2020 12:03:40 GMT In-Reply-To: Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org 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_PASS=-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:259875 Archived-At: Hi Alan, >> This is normal again, C-x 8 RET starts an operation which uses the >> minibuffer, and the cursor leaves the buffer in which you are and moves >> to the miniwindow. As explained above, when an operation which >> activates a minibuffer is used on a frame while other minibuffers are >> active on another frame, they are moved to that frame. I honestly >> can't see what's wrong with this. > > I can see a lot wrong with it, from a UI point of view. Whether the MB > gets moved depends on _how_ a user enters characters into C-r. This is > bad. The MB should either move when you type C-r or it shouldn't. > I disagree with that explanation. You do not "enter characters into C-r". When you type characters after typing C-r, they are displayed in the echo area, but that doesn't mean you enter them there: the cursor does not move there. When you type C-x 8 RET, the cursor moves into the miniwindow, and at that point you type characters in a minibuffer. > > Emacs 28 fixes this. > At the cost of breaking a longstanding behavior... > > Also we shouldn't force users to have to understand the difference > between the echo area and the minibuffer. Some of them will understand, > many will not. > That's a basic thing to learn when you use Emacs. And it's easy to understand: the echo area is for "status messages" with which you do not interact (and this is visible because the point does not leave the buffer in which you are), minibuffers are for "commands" with which you interact (and this is visible because the point moves from the buffer in which you are to the miniwindow). > > That most of isearch uses the echo area, but some of it uses the > minibuffer, is an arcane implementation issue which users shouldn't have > to worry about. We should leave them in peace. > I doubt a user who does not understand the difference between the echo area and the minibuffer would use C-x 8 RET during an isearch. And even then, with the above explanation that difference is easy to understand.