From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Sat, 28 Nov 2020 17:10:50 -0500 Message-ID: References: <53833023-d959-07af-7611-aa2e0bdcc1bc@gmx.at> <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3431"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Andrii Kolomoiets , emacs-devel@gnu.org, martin rudalics , enometh@meer.net, Alan Mackenzie , Eli Zaretskii To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 28 23:11:36 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 1kj8RM-0000nX-3A for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 23:11:36 +0100 Original-Received: from localhost ([::1]:59472 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kj8RL-0005y1-4o for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 17:11:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37646) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kj8Qm-0005Sr-Ha for emacs-devel@gnu.org; Sat, 28 Nov 2020 17:11:00 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43299) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kj8Qk-0007ks-9c; Sat, 28 Nov 2020 17:10:59 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E0BA780922; Sat, 28 Nov 2020 17:10:56 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 36A44801F3; Sat, 28 Nov 2020 17:10:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1606601451; bh=QjRwbcrVXTf+D0KrAfeT4VLG8C/y86jxsLWBLEj80us=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=HR1iy3Yzt+qnhc8HLfEyAXpp4JaYOPDX6Adnl5P5cNb1wDksm/b3ApCW6DOKFNok0 PrH8P9RGZ/76CoE25FslSEb5fau2utpqiJBGeJRqt0GnxBhKOMHTyfDca96ujYqvJj ZqOLNj4EJw9cyNBiYPBAa93WUzS9EvfqqJWFwZtgSsLvay5VIsitzh2LXHiMLjdUo7 XSAuot6hKdQibwD/iwEte79COjjmwCqPM12SrExCiMrxJc6JKWxkWm3b3m9aXo2k0d hMBdJ16C5iUQGITvYD2ASWmJ+yg+J+AzjiZ65pc2cXFChrS03v01ThtZYoODZTwI9u 686JZrTD/hRlw== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CEE1412032C; Sat, 28 Nov 2020 17:10:50 -0500 (EST) In-Reply-To: (Gregory Heytings's message of "Sat, 28 Nov 2020 22:01:35 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:259979 Archived-At: >>> Isn't the main reason for this that it has never been possible to >>> interact with a MBn when a MBm, with m > n, was active? >> Well, it's at best an indirect cause of the bug, but yes, it's the reason >> why this bug wasn't visible until now. > Put another way, is it not problematic to interact with and/or terminate > a recursive edit while one or more higher level recursive edits > are underway? I think "interact with" should be OK (I can see situations where you'd use two minibuffers, where you copy text from one to the other), but since the invocations have to obey the nesting, exiting from the non-deepest minibuffer is indeed a problem. We could start by signaling an error when trying to exit the non-deepest minibuffer? > Do you think the recipe with more than two frames I just sent > demonstrates a bug? If you're referring to the recipe to which I responded, then yes. Stefan