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#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active Date: Sat, 10 Jun 2023 16:51:47 +0200 Message-ID: <8a540045-0f14-43cf-0515-4dcab2f68b98@gmx.at> References: <83o7lo28e6.fsf@gnu.org> <0469e0cb-4f63-eb4b-1184-2dfeabdcf9e6@gmx.at> <83y1krzpoy.fsf@gnu.org> 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="35330"; mail-complaints-to="usenet@ciao.gmane.io" Cc: al@petrofsky.org, 63967@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 10 16:53:27 2023 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 1q7zy3-00092U-Eu for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Jun 2023 16:53:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q7zxg-00023d-AE; Sat, 10 Jun 2023 10:53:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7zxf-00023T-07 for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 10:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q7zxe-00035m-N1 for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 10:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q7zxe-0006je-4O for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 10:53:02 -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, 10 Jun 2023 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63967 X-GNU-PR-Package: emacs Original-Received: via spool by 63967-submit@debbugs.gnu.org id=B63967.168640873025823 (code B ref 63967); Sat, 10 Jun 2023 14:53:02 +0000 Original-Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 14:52:10 +0000 Original-Received: from localhost ([127.0.0.1]:36101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7zwk-0006iO-4K for submit@debbugs.gnu.org; Sat, 10 Jun 2023 10:52:09 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:54095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7zwe-0006hm-3c for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 10:52:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1686408710; x=1687013510; i=rudalics@gmx.at; bh=Mr6AHb3SgrOjwE/fvURt9CsqrcgtqhcDaE8rbG4N2Tw=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=oal3XZVueiaqfBdhgRZRBcAqgyJURyI7Dz6kROKYJ9roupW1wK/buhvcDOPD6KlPKBdPPmL B3ggqDNbzYvj3dCffmBiB5aZUZswsHFtHXmrqrAKzfb2drNMD3uIYDslH7NUCeiMGiB9IQW6x H44vPiom0+4QrZN2aaLGVwIk0/nnaGHzDPo7Yc3bnUF0x3H1Pcdb+f5JPc/I9dfteMmU2o541 /DguLcjdCzmVf+AOHbqy1y0ffP/83qPFxV81S1ie/JfpTpdQzj+m5GTKGCWU5yTmJaRYDX4u8 530mMdggo3A92Wo1eXV1+G4UMlbozkKj0MAqdjN7hSBIrs3JtLBw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.1.100] ([212.95.5.151]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MNKlu-1qWp1o0KOw-00OpGw; Sat, 10 Jun 2023 16:51:50 +0200 Content-Language: en-US In-Reply-To: <83y1krzpoy.fsf@gnu.org> X-Provags-ID: V03:K1:PwH3tS/cmKon4G/I4v9y+6hJUHOHIVnH0uapdiMqRd82/7bvJ1w wE7xUxK1qavHz+7fC+OiDCn0Yt7Wrnm7cavcNf/kiZW2fvGFEjfjfWgj3Wxy2sRy7ApRBub 14Bl4x2cV1R7dQHxyt87suHiqL38R7E8Htp5e0m07hplrdTxvfWi8+rU0g+ZII9Xz36ywgE oIydbOeM8BqvmFx+8JkLQ== UI-OutboundReport: notjunk:1;M01:P0:QasbAIWb/3E=;Y4qH2XPI3xeXPXDUKwT2xfqnmT7 4oZhZx6wi4avFZ5AcpkNAtScw41kWJtGD5dozvi02hs4VgeHjjzSNBGIYkH/XVl8C+k86Sglr QeH5KNMrnhMoJ2xGDN6Vh5fMMBHDc0FEq7kXM4Gw9zJXwzzwS2m2voPlhRCullgoMM6uWicfU sE1TXDJNVqAUcipxRRrKlgHjpNPSyL59fHp1zYx/dA85HJAQka58+0+mpOzzxuE3CU4bhK7na TetEjPkr1v4e1phe/FuHGBp7JJjCHfZkkPfQcypKrmklBHlaCS6pXr+1Jof4BHLavJo9oc15k 8oo7NHIVlK0ZKZFIy51SSLObsKWAp8yrJLcL0gZY3NrgiVN7qqHZ7VI1XiCsAt4GOYNy5xY55 /qH5JHvH0QROdQTGYEibD1AbosbOtnXr8kSicOo+Y4GNYIzfZwcTq4WF826mhEGdltuayQMBJ VxkBjpMpZ78ARQa7PlaHXPI2UCYJFrUfhIAQEd/eXyprwJ3us5ixio6DxGe50iXhvm1h8kJPz bW1bAI9OgHnnNx/eJqT9THbLEJz+FkzS/YKNublUpMzNK858hTFxeW0vNMspXJyy2oLvZpaMz z7wV6nKKHxKTEYSLnUIc/jOKgYoSNg48AFuGsXxcgaOSvSZMjyNZo4/Yu6bfapOuoAIEYVivA 9Ddm3EaBvmx3Az3NfT+zdVQkCA2W45dHDJWzCQUECBxygVF66X7+irW61VuO9/+hnIoRTiL3U /E/P4QQP4piOEci4UDda4RM0yZezNKI3HPNTdyBSyJxur3wwNVHZr2kRUvWse5vM/UZtepBc 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263219 Archived-At: > That works, but does it make sens to do the other stuff in that if > clause in that case? We do: > > if (!NILP (w->prev_buffers)) > { > entry = Fcar (w->prev_buffers); > w->prev_buffers = Fcdr (w->prev_buffers); > set_window_buffer (window, Fcar (entry), 0, 0); > Fset_window_start (window, Fcar (Fcdr (entry)), Qnil); > Fset_window_point (window, Fcar (Fcdr (Fcdr (entry)))); > /* set-window-configuration may/will have unselected the > mini-window as the selected window. Restore it. */ > if (!EQ (orig_selected_window, FRAME_SELECTED_WINDOW (f))) > Fset_frame_selected_window (exp_MB_frame, window, Qnil); > } > > Does it make sense to manipulate the buffer, window-start, and > window-point of WINDOW if we are not going to make it the selected > window? If w->prev_buffers gets us the right minibuffer to display here (any former dw->prev_buffers = sw->prev_buffers should guarantee that), then for that buffer we have to establish the corresponding start and point positions. This makes sense regardless of whether the minibuffer window will be selected or not. IIUC the present code either assumes that the user was in the minibuffer window before starting the last read_minibuf interaction or that Fset_frame_selected_window does not select the window when the frame is already selected. > In general, I don't think I understand the logic of this function at > all. Since this is about the "expired minibuffer", then the code > seems to assume that when a minibuffer is "expired", and there are > previous minibuffers for that mini-window, the mini-window stays the > selected-window? But that is not true when recursive minibuffers are > enabled, right? More precisely, it should not be true when a nested read_minibuf was invoked from a normal window as with C-x b, something that can happen only when `enable-recursive-minibuffers' is non-nil. This includes the simpler C-h f C-x o C-x b which means that a user does not have to enable them explicitly. > IOW, I wonder whether your suggested change just postpones the problem > by moving it to the rarer cases when more than one frame is involved > in this dance. Why is it okay to set the selected-window of another > frame here? I wouldn't know. That's why I called my proposal "timid". martin