From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Tue, 5 Jan 2021 19:53:23 +0100 Message-ID: References: <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> <50c96c83-01b4-d2b8-ff90-82c9d706e268@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32471"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrii Kolomoiets , emacs-devel@gnu.org, enometh@meer.net, Stefan Monnier , Gregory Heytings , Eli Zaretskii To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 05 19:54:17 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 1kwrTF-0008M4-2P for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 19:54:17 +0100 Original-Received: from localhost ([::1]:43658 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwrTE-0007jr-4j for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 13:54:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34498) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwrSg-0007Dr-FF for emacs-devel@gnu.org; Tue, 05 Jan 2021 13:53:42 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:43709) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwrSe-0002e3-Kn; Tue, 05 Jan 2021 13:53:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1609872806; bh=Rqt3g9oZg44LnBMacKXmwroxrYn7rzqtoxLL5EKEl+M=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=QpIKNTkDHMa4l5cACbClBztBnceFsoQ/Kteot04VimeMXzHUfRXSDEhOsCE9xZzfK 9vZLx42u8mIQXpzMYElTSA690nk3F2+6NAY2WuvrUp2dcUPi2XtL7s+W7iBOQNxOs2 xcRsmISGy+bZhDQAc4F0ZDkvYLPuB+4pg33tReE0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.231]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MK3W0-1kgzIe32p4-00La5g; Tue, 05 Jan 2021 19:53:26 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:QRpzFIblGjcgeSawa3IrSt7rqmTfWIgSGFUhCO6fPPrWdi2Xipe 6QH930mgIGVE9yl6U54CiWoRZ3+C9gBiUFVjsQu0LXRry7qJDazktHFAVEE/S/GTnfQQWk+ +Z0yWHJWpSCaye2d6VOomoBGkEETJRvDOrYrytKa6ibFsT+fUXlyqaETr66ZP3z60v8HEVd U3xXHIo9Nt0vR9jhJuzWA== X-UI-Out-Filterresults: notjunk:1;V03:K0:w50QCQYc3vs=:VMKStnSSIOujRkW8s5EQi7 JqYKQ0VNXLvDJtgcYmVjoNofFAMWaNiWZPCnraJp0tKYiiygrMCRF3eSv8uDZj4trHqdC351m ujJPVFhYL3kR7Nhm2dD3PYKslQUbWEwIZdzXzMQZrhfpP1LWSjyhTOXF0jWhxGzcLvMvM/vTZ cW6t9c7oWIXX7/EuAVRbasoW8wy7UMUSHFKt9djuXY2I9yxul50qMN9twojygON21dNxecr04 hdfOZsuDFRWuFxovv+TKm2CuFb9+wP+52eiiZgTOo0xjwldxiYUj+YX6JNdBShPb7U3w+jFiY HgQNZl0B2WVi8xa24DlVjRRKt/dc/xLAiCt1BsB+2QdxU6VYS8G+RLiDl8T388NrRiFdj8fdr SJY74SZT3sTEiqOvF2Ae+NN66vJEv1QhZE2cxURzQpxBUzEPrljZSJ0fzqNeM4er8WMDyvWrW lcZibfEZE0Rw2hRpQy5Q+7q4OYGQgBqr6zT47bcMsE5m7qnrgL4cUidfXefAiMqcEl0P+6VOM RB3VtYUJhlydUSiv8MIiCa+e1NAt8ACmMEX2EkO/aCY/uPeXPiGt7kQn/sUBwClvAVGterKeh hbKCeAcvq/YFWzRuFk2kuOiLS518nXp8Rg9cin0PFBFXDaR5epb7cWgIMs6TQH51qwW5d3Ht3 aRywYYL6l5L8oRg1ZR7u+rZrluCmTNvdlmm/0xCCNs2kKBop7jk8nTz8U6a6RTU6kFoE+LrFz E1sYo37WR30noFGwsNW4Aj/sCfU0SOFt4NzPAgDrZYlm0Jp5BGFmfFuj9kOSaX7r4+drh6xz Received-SPF: pass client-ip=212.227.15.19; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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:262536 Archived-At: >> - doesn't get me _always_ into the minibuffer window of the frame >> switched to (I'm not sure whether it should and under which >> circumstances - this should be clarified), > > I don't think it should, in general, unless the miniwindow is (still) the > frame's current window. OK. Let's stick to this rule. > I've found out why, in Gregory's scenario, after the "middle" RET to > visit a file, point was not moving back to the "middle frame": it's > because select_frame is insufficient of itself to move X-Window's focus, > which stays in the "old" frame. Any command now causes a "switch-frame" > event which moves the minibuffers back into the "old" frame, which isn't > what we want. The solution (a bit ugly) is to call the lisp function > select-frame-set-input-focus rather than just do_switch_frame near the > end of read_minibuf. This is indeed ugly and might harm 'redirect-frame-focus'. >> How do I edit an outer level minibuffer whilst an inner level buffer is >> active? > > At the moment, you can't. This isn't good. I think it is good (enough). Do we want spaghetti minibuffers? > What do you think of the > following solution? > > Instead of setting outer minibuffers' maps temporarily to > minibuffer-inactive-mode-map, I could amend exit-minibuffer so that it > would throw an error when there was a more nested active minibuffer, but > leave the current minibuffers untouched. Also, C-g should then abort the > current minibuffer's caller, together with those of any more nested MBs. We're right in hell's kitchen here. > The change in the current version of the patch (attached) is that, as > already mentioned, select-frame-set-input-focus is called rather than > just do_select_frame from near the end of read_minibuf. Also, that call > has been moved from just after the recursive edit to the very end of > read_minibuf. Also, move_minibuffer_onto_frame now moves the entire > stack of minibuffers, not just the current one (it is not called when > minibuffers-follows-selected-frame is nil). > > How would you feel about committing this patch? It is an improvement > over the current state, even though not yet finished. Let's wait for a week at least. I'd really want to hear the comments from the rest of the bunch. martin