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 12:02:34 -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="36372"; 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, Gregory Heytings , Eli Zaretskii To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 28 18:05:17 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 1kj3eu-0009LL-PP for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 18:05:16 +0100 Original-Received: from localhost ([::1]:47652 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kj3et-0003Pk-QL for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 12:05:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37142) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kj3cQ-0000V4-KB for emacs-devel@gnu.org; Sat, 28 Nov 2020 12:02:42 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29292) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kj3cN-00064l-Oi; Sat, 28 Nov 2020 12:02:41 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 90D7110025D; Sat, 28 Nov 2020 12:02:37 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0808F10019F; Sat, 28 Nov 2020 12:02:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1606582956; bh=qwB1d2WfTyNeUETAXpUeOkDE+7Es+F0h11CGFZ8vywc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=EWmNN2h0/C8diTlS2lHhSAI3f9bQXNpu5LNXSydOU+vvkfyYgJrUzOodamq3An9fy wHJBryBaMWwwTkIjEPssrEjtZCoj4L4EeXk4JVgDY66JDWJ7eA9lvvjqyvqu6J/FJF FyWGxt19JxiIpSEM/F2I8ke5j2wL+kztdAYRxdh4wetprAmPBxUqDd0rtEFxjQmxh1 SYzaWv2ekw8lYqY7hLFJM2BWxk+nPcDVT52bFGfpom9SGn7Ojy6AZJQpFfp11Xoe5f 2hRhOc89Y+c7Da7btCUM8jD9u2E+DL1QjMmu8wYIkhGBxtPSK4yFoHbJThEhWarbWg uKkunUsqrbmrA== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9EDD41202F7; Sat, 28 Nov 2020 12:02:35 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Sat, 28 Nov 2020 10:45:34 +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:259959 Archived-At: >> A: type C-x C-f on frame F1, switch to frame F2 >> B: type C-x C-f on frame F1, switch to frame F2, type M-: > >> [1] There is also a severe regression in this case. Type C-x C-f on frame >> F1, switch to frame F2, type M-:. "Find file" is still visible in the >> miniwindow on frame F1; switch to frame F1. > >> Experiment 1: Type the name of a file and RET. You'll get the error >> message "End of file during parsing", and MB2 on frame F2 will be left. >> MB1 is now unuseable, and impossible to leave, it will stay on F1 whatever >> you do. > >> Experiment 2: Type C-g. MB2 on frame F2 will be left, and "Find file" >> will stay in MB1 on frame F1. However you cannot use it anymore, the >> keymap of MB1 is now minibuffer-inactive-mode-map. And like in experiment >> 1, you cannot leave it. > > The abstract cause of this situation would appear to be using F1's > minibuffer while a more deeply nested minibuffer is still active. More specifically, it's the act of leaving MB1 when there's a deeper MB2 active: the code for leaving a minibuffer (e.g. `exit-minibuffer` or `abort-recursive-edit`) doesn't actually pay attention to which minibuffer is currently being used: while it's run from MB1 it actually exits MB2. I'm not completely sure why we end up with a broken state, but I guess it's because some of the code that "deactivates" the minibuffer upon exit in run in the minibuffer that the users thought they were about to exit rather than in the one that is actually exited. I expect that this is the core origin of the problem. One way to address it might be to make every minibuffer use a different exit tag (instead of the constant `exit` symbol), so that the `throw` will not be caught by some unrelated `catch`. Additionally, we may want to tweak `exit-minibuffer` and `abort-recursive-edit` so that the user is warned/prompted before "silently" canceling that other (deeper) minibuffer. [ Another way to attack the problem would be to arrange it so that every minibuffer runs in its own thread, so you can exit one without affecting the other. I think it might be an interesting direction, but it's probably not trivial. In any case, cmpletely out of scope of the present problem. ] Stefan