From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame Date: Mon, 18 Jul 2022 10:58:09 -0400 Message-ID: References: <5d86d890-9a2e-e4d6-13fb-da03285ea003@gmx.at> <61fe102b-eec2-9711-560e-c141ed3cc6e4@gmx.at> <171bab25-5eb2-884b-5c32-bcfe4fed21cc@gmx.at> <11e7e566-f626-fcf4-adfc-d03efa0d861c@gmx.at> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19436"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Alan Mackenzie , Eli Zaretskii , 56305@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 18 16:59:11 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 1oDSDH-0004sT-5d for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Jul 2022 16:59:11 +0200 Original-Received: from localhost ([::1]:50054 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDSDG-0002dQ-7K for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Jul 2022 10:59:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39278) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDSD8-0002dI-VY for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 10:59:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54056) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDSD8-000565-N2 for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 10:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oDSD8-00081c-Cr for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2022 10:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Jul 2022 14:59:02 +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.165815630430793 (code B ref 56305); Mon, 18 Jul 2022 14:59:02 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 18 Jul 2022 14:58:24 +0000 Original-Received: from localhost ([127.0.0.1]:51815 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDSCV-00080a-RS for submit@debbugs.gnu.org; Mon, 18 Jul 2022 10:58:24 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDSCR-00080L-Ei for 56305@debbugs.gnu.org; Mon, 18 Jul 2022 10:58:20 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CB70544165E; Mon, 18 Jul 2022 10:58:13 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 34AD9441634; Mon, 18 Jul 2022 10:58:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1658156292; bh=56oOScZcsxr8WmKiF7MNuErod2wlNdXDvcM5qFhI2vU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JKitQZUnbRDzIQK/LUaoIsZkWDAXC6CKeXzzdHNdrYoPW8s5ta8tAPN4zFXkWag6H s+wsmY1G7rJbG8DtkLiDksz0Ct9OW9BpxThNLpYTIR3WcxbwiIToQCwh16HIGSr8Rz 2LBrsVFD7kTlHma9eeF6FeKzx4b80ma7iStz7dKG2Y2RMt14/JokoogcBWa+PBB1kI CQt3Xkqd+Nq9CuS8vDdmOERIPMKKgYJxw0YHRoMrTV6mCOn/IwPFziI4H+hQn7Z9x3 BNX+aTn7+MKsCol7h2ooBX7oQF6fupku0uFbKqYKDw80HLMrkHH6s4TsQHGh7B2sZK hqfF241S6xgaQ== Original-Received: from pastel (unknown [45.72.196.165]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EB43A1203D6; Mon, 18 Jul 2022 10:58:11 -0400 (EDT) In-Reply-To: <11e7e566-f626-fcf4-adfc-d03efa0d861c@gmx.at> (martin rudalics's message of "Mon, 18 Jul 2022 09:37:35 +0200") 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:237357 Archived-At: >> In case you intend to fix this apparent blunder of mine: the point of >> that commit was to set the selected window and frame so that ELisp code >> run from the `mode-line-format` would see meaningful and consistent >> values of selected-frame/window (and companions like the >> frame-selected-window of the selected-frame, ...). > How are display_mode_line or display_mode_lines affected by that commit? I'm sorry, I don't understand the question. > Worse even: People who want to know, for example, whether the mode line > belongs to the selected window have to use 'old-selected-window' for > getting that. Not sure "worse" than what. Clearly when computing the mode-line, there are 2 windows of interest: the one to which this mode-line belongs and the one that's currently considered (from the outside) as "the selected window". Only one of the two can be "the selected window" while computing the mode-line, and in my experience most code wants/needs this to be the mode-line's window rather than "the one that's currently considered (from the outside) as the selected window". > And by no means I'd ask for changing this. But a better explanation in > the doc-strings and the manual should be in order. End of the aside. I didn't know that `old-selected-window` could be used for that (when I installed the patch, there was simply no such option and my recommendation when people needed such a thing was to use a `pre-redisplay-hook` to set some global var to remember the window that was selected when entering redisplay). >> If calling `Fselect_window` with a non-nil `norecord` argument messes >> things up somehow then maybe we should fix `Fselect_window` accordingly, >> or otherwise provide a "more bare bones" function that DTRT. >> >> It seems clear to me, for example, that when called with a non-nil >> `norecord` (like in the mode-line code), `Fselect_window` should never >> cause any change to the focus redirection (or the focus itself). > > NORECORD is not about focus. Then we need something like it but to say "I just want to change selected-window temporarily, so don't mess with focus or any such thing". Or maybe, an alternative would be to wait until the next redisplay to reflect the effect of select-frame/window on focus. >> I can't see the connection between these bugs at the above commit, sorry. > They are a direct result of x/gui_consider_frame_title calling > Fselect_window calling resize_mini_window and were fixed by binding > 'inhibit-redisplay' appropriately in x/gui_consider_frame_title. Hmm... following the idea above, maybe select-frame/window should never call resize_mini_window, and instead that should only take place at the next redisplay. Stefan