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.bugs Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame Date: Mon, 18 Jul 2022 09:36:28 +0200 Message-ID: References: <61fe102b-eec2-9711-560e-c141ed3cc6e4@gmx.at> <171bab25-5eb2-884b-5c32-bcfe4fed21cc@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="38231"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56305@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 18 09:37:25 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oDLJl-0009rQ-KT for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Jul 2022 09:37:25 +0200 Original-Received: from localhost ([::1]:36324 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDLJk-00055i-AV for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Jul 2022 03:37:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48716) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDLJP-00054B-7M for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 03:37:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51345) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDLJO-0000EB-7m for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 03:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oDLJN-0002BE-SK for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 03:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Jul 2022 07:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56305 X-GNU-PR-Package: emacs Original-Received: via spool by 56305-submit@debbugs.gnu.org id=B56305.16581298098362 (code B ref 56305); Mon, 18 Jul 2022 07:37:01 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 18 Jul 2022 07:36:49 +0000 Original-Received: from localhost ([127.0.0.1]:49104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDLJA-0002An-SJ for submit@debbugs.gnu.org; Mon, 18 Jul 2022 03:36:49 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:41729) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDLJ5-0002AL-20 for 56305@debbugs.gnu.org; Mon, 18 Jul 2022 03:36:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1658129790; bh=s4poaNTOMk1f49nmaxjZbQ41uI64wDblw8jW+KEA4OE=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=PxaeFyp4KpqOr0dC0tzp/4Eqxjgnq5Vxju+SfnI0uZ3x8WakDwvJywr+4AhTARd+1 v9AJL+UYBhCPNOzANpMspt5tTYX0QersGg2Mk6JwBAFYdCIxssumvB0UAuH6tFE32O 5rWU4Yw+fl9FHtsfUSJMAZ3p1VkLLvf60WgJk+SU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([213.142.96.153]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTRMi-1o5jV433Qi-00ToHH; Mon, 18 Jul 2022 09:36:30 +0200 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:Tyd58ri3/U719d8rVRw1UQ48KAXJzTM0q++n8652XnC7QXDbzsG u5O/4mKUj6OeagwDhJ+2K4ESYpzdtm7JhNWIk5dOu7xAMXq7H+3gOP50FXdD2TuXGrU3xkb KvhrtDKl0na4cq82nFM1IrBrAURzBsLhnOGLDh81hAvFTQPvgtnEEPe/eRd0KCKRfZ4hiDL +p2RxSRymsOFjNjDakyig== X-UI-Out-Filterresults: notjunk:1;V03:K0:vueHYGzM8/w=:Iv3bkQwVC6HDCbAQWHdQHX oMRG2lt+dkkmBNb2SBmk6BItwGKi77XkxdDRWLE1yMWBNWUy9GVOIXI951DGqkNUDo1WHaFyT aBgmINcOibYG2psNZIn7NZNjtoiH6Iu2hFWfeHawT/nTBsWEFFKj8A2oNoBSIsY60EnBwrkCi 8rMMoFVvKt7OtXrP9ryu/yNslmn5HdlA/b0nGiYg/Xlskx0qyBBUJQaXrT/LaQgoH0eenyTE5 ZK+tHkw7BwxfpAC5eiPSZy4xB66GCj4o+3FgL6rOWbzI7Qknc+FSAgxt1JaNs7LRJzkm+4Q7k aEo1/P/gkcLvjS+i2wwq3njRG3675bwqFqzlDdLDsLPP7PI2fbJE38KCZyENWpy7LGfgtAngU QGkreiISDfi3Mc021Cgbmj0MabVEil4v+vcpqEmtOKW36Y9WzxcQGWHa/LslRza+Cfmu5PO6q Kzt1+K8HXJxc2bZVdYu3IzqARnn2flBSwOuwpaPTQwUg3u+BERxBqd+8diK+E1E2bxQq2y1lY 0MyK4n0bIlTNRKbMBNHI6UrSBrrLRroQ3ggb/ElicfdqEcMdhfK88v1PWLWJuV25S888qmA0I Ta2GpiNVIxfHKeIPUAlnP1Cl3SFdSX02GExXkDidqyxZpKCWU30UOy0XdU2v4IGHUUTW9LFYD aLy5k4FBIvcVY1vXw43TrL1R/HHq2wkwLHAUHW9Rh6SSN5alXEY9QKf0eypH+SDjGIHrqV6fg c3N8qR2rBFlJ7jrhToxDpkFF36oji44U1G03Pv5de33pDFQGQo5EnKnQsRT724yFDWAac4iy X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:237329 Archived-At: > Doesn't terminfo cater for this sort of thing? Whether it does or not, > surely we could set up a set of capability variables, nil/t, a bit like > we've got focus-follows-mouse. The doc-string of 'focus-follows-mouse' says: You should set this variable to tell Emacs how your window manager handles focus, since there is no way in general for Emacs to find out automatically. So do you mean to add similar options that allows users to tell Emacs how their window manager is supposed to behave wrt foucs handling, frame raising and the like? I suspect most users have no idea how their WM behaves in these regards. In either case this would be only tangential to the current issue. > Again, where are our capability variables? Maybe someone can tell us. > C-x o calls next-window and the spec for that, with arguments like > ALL-FRAMES and MINIBUF is right on the boundaries of understandability. 'next-window' tries to handle every possible use case instead of DTRT in the few practical cases. But that ship sailed a long time ago and now we can only try to keep the old behavior in place as faithfully as possible because there are too many callers out there that might depend on its once established functionality. > It strikes me it was really fragile code. In the middle of the function > to switch the current frame there was a difficult to understand ad-hoc > section which redirected the focus, sometimes. Surely that should be > done somewhere else (where?) more systematically. do_switch_frame was Fhandle_switch_frame which was Fselect_frame. Once Fselect_frame itself accepted 'switch-frame' events (that's where the "if (CONSP (frame)" part comes from) and asked for redirecting frame focus. Later Fhandle_switch_frame was invented to handle requests coming from Fselect_frame, Fdelete_frame and switch-frame events. Then do_switch_frame was invented and Fhandle_switch_frame became a wrapper for that. In 2001 the code for resizing the minibuffer window was added to do_switch_frame. In a nutshell, all these additional functions were provided to better sort out two underlying behaviors: (1) The WM tells us that it now will direct input to another frame and Emacs must select that frame in order to stay in synch with the WM. (2) Emacs wants to change the selected frame and we have to inform the WM about that change so it will direct input to it and call us back via (1) that it now will do so. Be it as it may, the history sketched above should tell C coders to refrain from calling anything that could end up in any of the functions mentioned above plus Fselect_window which ends up calling Fselect_frame when the argument window is on another frame. These functions may do lots of things other than resizing minibuffer windows and redirecting frame focus. Why on earth should title bar formatting do any of the following: - set f->select_mini_window_flag - mark the window for redisplay or ask to redisplay_other_windows - call bset_last_selected_window - call move_minibuffers_onto_frame - set last_nonminibuf_frame - set internal_last_event_frame > I think we can understand the motivation behind that. Fselect_window > will surely do everything to keep everything consistent and coherent. > Just setting the variable is liable to lead to inconsistency and chaos if > you're not very careful what you do. This pattern is not unknown in > Emacs, where a high-level function (or command, even) wants to do things > which are inconvenient at the nitty-gritty level. If that were the case, then mode line formatting should have called Fselect_window long ago. But Gerd's code from 2001 which "just sets the variables" is still around and handles that case without larger complaints ever since. We fixed the case where a frame's selected window was not in synch and one where a window got deleted by the mode line formatting code in between. > I don't recall seeing > any comments about Fselect_window saying "be careful!". I'd always try to "be careful" when calling a primitive function from C. >> In the sequel, obscure bugs began to pile up, all very difficult to >> describe and reproduce (Bug#23124, Bug#24285, Bug#34317) and were fixed >> with some trickery. The origin of all that evil remained in place. > > What is stopping you fixing it, given that you understand it better than > anybody else? Irony of sorts? The patch I proposed was categorically refused. >> Making the minibuffer follow the selected frame was just the final >> stab. > > That's optional: now, either the MB follows the selected frame or it > doesn't. Setting 'minibuffer-follows-selected-frame' to nil doesn't prevent the bug from happening here. > Commit 6355802033d202....aecceef? Why not? Because we had that in Emacs 28.1 and you reverted it for Emacs 28.2. martin