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: Sat, 16 Jul 2022 09:06:00 +0200 Message-ID: References: <5d86d890-9a2e-e4d6-13fb-da03285ea003@gmx.at> <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="39572"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "56305@debbugs.gnu.org" <56305@debbugs.gnu.org>, Eli Zaretskii , "monnier@iro.umontreal.ca" To: Drew Adams , Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 16 09:07:13 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 1oCbtQ-000A8G-O6 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Jul 2022 09:07:12 +0200 Original-Received: from localhost ([::1]:40678 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oCbtP-0006aN-N6 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Jul 2022 03:07:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44182) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oCbtG-0006Yw-ER for bug-gnu-emacs@gnu.org; Sat, 16 Jul 2022 03:07:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45054) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oCbtG-0000qt-5y for bug-gnu-emacs@gnu.org; Sat, 16 Jul 2022 03:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oCbtF-0000kf-TO for bug-gnu-emacs@gnu.org; Sat, 16 Jul 2022 03:07: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: Sat, 16 Jul 2022 07:07: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.16579551842839 (code B ref 56305); Sat, 16 Jul 2022 07:07:01 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 16 Jul 2022 07:06:24 +0000 Original-Received: from localhost ([127.0.0.1]:42813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCbse-0000ji-2t for submit@debbugs.gnu.org; Sat, 16 Jul 2022 03:06:24 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:41867) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCbsb-0000jT-KV for 56305@debbugs.gnu.org; Sat, 16 Jul 2022 03:06:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1657955163; bh=d/fNy/FgO4bPWu+jmsAtj3ylkat7SOPdqgmXJmB4Flg=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=YkzOWOJoY7Kf/9KEfF9Nl3lWpYtip2my1yrUn9VBu5xxsZeHs3AZtJUguxoGgHJG9 WvcXrf13taDLO7zbWyEfMHipaqI4bKvj2A/W2raarVGzRyq3ZfZUSpQw3IEkbZrPrk ej7tIV4YahVfEUwmLLsLLEPIl8sfMOoa3DjoqAUE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([46.125.249.70]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M89L1-1o7wu818KZ-005FIK; Sat, 16 Jul 2022 09:06:03 +0200 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:1rS1IRR6nr3nhJkWKOVO5/GgYWF9r5tNxJsVDXRVOSHsF3T35i5 t+rwYPLuCyHQxEMVCJVOqEZSzWy2XKYFRdPDsctbKxdKq6TYKr27hggHCjtuRm/08xxcb25 CkDfPHLJiSPYf2Seq/DL3dn06FOvoO+k2IK+7MtwBXYEJtHwBbE/ympHe0NrtPsUKmOczXx YA4Go3bC6fG/uLVI5oi0A== X-UI-Out-Filterresults: notjunk:1;V03:K0:4EcQC1cUp4g=:ybL0kQDq1heHKK9AgKB+Se DQsIsAwZTfQZgPolOlQq67XGf4GzpNTX5gudRNQNdMlMQucPcKxQ348mnXF+SOzBfx0rEL/5H zrmiax5P7a5ekFsQ/LQSAt1PEZmkxWg1sBQ2Zov+dn14euGzkzukFPefqoM1LOJgkOTlw9j6x ez4sSaoUv9QETLtQeeZdJLbO5UXFZbefL6uA+YfxCMIhziYJZOJv5FvpIiPv4FwpDvy5BDgKy fM5Jx+BGVe/iQOTurWQcRjNvK9P2tHFC8PJIqC+Ne6lrH/rjB2EbBV6gwlHMndsHEZlUaL9w5 kin55ct+n2zdRXCwExIkqvrT07T89KHkc6ii7RMTtafoY1uf/XHi3afWlay5IJFEyvhb7ekwE zxWazzobv1v32l0MO75nL1QLAY5M7zIZ3kQqoPt8v6NnMNAT137AST8NA2J796QmGwtWwW5dP i655+oNCj01WeEADcV/jOBCw+rgi6I+WUSxadvNCQexFGxaOqBNVRSLMOIW3L11ayzEZD5Tcz d2kNOuBlR5zpPHBfzFRaTOMIbNsz7frfvuyizcn5pX2n+bcvOWmHq4/RZjf8guYAcadp54E3i dtRkcBegld+yZ1GvC2Uv8lizcPW3rQ63RCHHjzud5GOSd7BzP9R82RIig+5YCzzpR0iWKE0X0 EUcn81uefNw+L/8em5wACzBl/aFz+FEuQ0PQ2uW5e0WWRs6K1JVaCiR0AnNMH8+Sn6/wPV+E1 LLPaUdvWTKwPgvhYyhqvardO0MGz5h0H5afSExF0/knsZDx8ImQals+YXdC5xBj6MlGVUkM2 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:237146 Archived-At: >> But if you display the buffer in a new frame and the window manager >> decides to always give focus to a new frame, that window will be >> selected. It took me years to convince Drew that Emacs can't do >> anything about that. > > Odd. I have no recollection of ever not being > convinced that frame operations are often beyond > Emacs's control (i.e., that window mgrs rule the > roost), or that `display-buffer' isn't, itself, > about selecting a window. Then how about This is driving me crazy. I've tried a zillion ways to try to work around this problem, to no avail. On MS Windows, whenever a new frame is created, it becomes "selected"/"focussed". I use quote-marks here, because I think it might be more than what Emacs calls frame selection & focus. I admit that it's unclear to me just what's going on. ... I've tried every hack I can think of, from saving and restoring the selected buffer/window/frame, to redirecting and un-redirecting the frame focus, to playing with before-make-frame-hook and after-make-frame-functions. I cannot get the new frame to become un-"selected"/"focussed" and let me continue to use the minibuffer for input. > As I don't follow commits, could you situate the > change you're talking about in terms of a given > Emacs release or past discussion (e.g. bug thread)? > I'm curious about what got broken when (and why). The original commit from 2008 can be studied here: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6355802033d202c63f6fff4b77bf2b0c7aecceef It was complemented in 2012 by: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c6bf30222430f41fbb696e296f0f63f465eefc35 I have not tried to find out which one is responsible for the current behavior nor which release first showed it. The oldest version I can build here is Emacs 24. Neither of these commits hints at a prior bug or discussion explaining why they were considered necessary. It's interesting that these commits, while mostly acting on the function unwind_format_mode_line, do not affect the formatting of mode lines via display_mode_lines because the part of the vector used by these commits is always NULL, nil or false there. Hence the later check if (WINDOW_LIVE_P (old_window)) always fails when called from display_mode_line and display_mode_lines correctly restores old window and frame via restore_selected_window. Restoring the current buffer could be the only worthy contribution of these changes but ironically is not done from display_mode_line - the second argument of format_mode_line_unwind_data being NULL there. >> We should eliminate the original sin and be >> done with it once and for all. > > Probably easier said than done? It's trivial because display_mode_lines handles it correctly. The only difficulty is to convince people that the commits mentioned above are fundamentally flawed. So far, my explanations have been met with cold disregard. martin