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: Handling minibuffers in several mini-windows Date: Fri, 8 Jan 2021 18:54:03 +0000 Message-ID: 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="27638"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 08 19:58:39 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 1kxwy6-00075b-Ov for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Jan 2021 19:58:38 +0100 Original-Received: from localhost ([::1]:32996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxwy5-00030V-Mh for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Jan 2021 13:58:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34676) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxwtn-0006D3-BH for emacs-devel@gnu.org; Fri, 08 Jan 2021 13:54:11 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:40976 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kxwtk-0001XK-GP for emacs-devel@gnu.org; Fri, 08 Jan 2021 13:54:11 -0500 Original-Received: (qmail 86665 invoked by uid 3782); 8 Jan 2021 18:54:04 -0000 Original-Received: from acm.muc.de (p4fe15a52.dip0.t-ipconnect.de [79.225.90.82]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 08 Jan 2021 19:54:03 +0100 Original-Received: (qmail 8995 invoked by uid 1000); 8 Jan 2021 18:54:03 -0000 Content-Disposition: inline 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-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:262771 Archived-At: Hello, Emacs. This post probably belongs in the thread "Stop frames stealing eachothers' minibuffers!", but I think people are beginning to suffer thread-fatigue wrt that thread. Only Martin R. is currently posting things to me in that thread. (Thanks, Martin!) The problem arises when minibuffer-follows-selected-frame is configured to nil, thus allowing several mini-windows to be simultaneously visible in several frames. As long as the user attempts to use only the most deeply nested MB, that isn't a problem, but when she tries to type into, terminate, or abort another MB, we've got to decide how to handle it. My proposal (which I've already implemented and tried out, though not published at all), is that (i) it should be possible to type into, and edit text in any visible minibuffer; (ii) it should be possible to terminate (by RET `exit-minibuffer') only the most deeply nested MB. The attempt elsewhere should display an error message, leaving the MBs unchanged; (iii) it should be possible to abort (with C-g `abort-recursive-edit'), any minibuffer. This will have the effect of aborting all more deeply nested MBs at the same time. What do people think about this? -- Alan Mackenzie (Nuremberg, Germany).