From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 11:28:29 +0300 Message-ID: <83y1krzpoy.fsf@gnu.org> References: <83o7lo28e6.fsf@gnu.org> <0469e0cb-4f63-eb4b-1184-2dfeabdcf9e6@gmx.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9176"; mail-complaints-to="usenet@ciao.gmane.io" Cc: al@petrofsky.org, 63967@debbugs.gnu.org, monnier@iro.umontreal.ca To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 10 10:29:19 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 1q7tyJ-0002Er-Gl for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Jun 2023 10:29:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q7ty5-0001Oh-UL; Sat, 10 Jun 2023 04:29:06 -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 1q7ty3-0001Nw-Dz for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 04:29: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 1q7ty3-0002k0-5d for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 04:29:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q7ty3-0001dd-1T for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 04:29:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 08:29: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.16863857086225 (code B ref 63967); Sat, 10 Jun 2023 08:29:02 +0000 Original-Received: (at 63967) by debbugs.gnu.org; 10 Jun 2023 08:28:28 +0000 Original-Received: from localhost ([127.0.0.1]:33209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7txT-0001cL-N5 for submit@debbugs.gnu.org; Sat, 10 Jun 2023 04:28:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7txS-0001c8-Hn for 63967@debbugs.gnu.org; Sat, 10 Jun 2023 04:28:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7txM-0002gj-UB; Sat, 10 Jun 2023 04:28:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=piC76RvRujKduoqnQVJVRzRxPhaXJapjKjrKf10Eplw=; b=HtAO9sKTsDv1 +cwaGVDxus7o/isU4lJ2/lSTwFMXoymGf11kRJ+7vMG2mD2UPHqU+S3yHalk1w/i/whhSMUw9P6m2 33m8f+L0yasIFTEzjfd+Wq6k+ThYMS/O56uEtOTqpe//gy/tAkgYhHAS3Z4eS5QxYc4HCbezZ/lQ5 tmi+nQGj9bmsv2O0FOZN7gVHuXr8DU5hnxj0uNwsXa0PcVLzyqz1EWPa9VR+RnhqV/JeApBnBGi8F o/mFLAi1W7EvVuO1L3N3DJL+dQI8E7wRwh4AVxmyVoSiaj6Xn6csARfJ0aqCP+Japj9FczdETQSNJ Frpu0bbb+RH77lUrRxw2Ig==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q7txM-00056U-1i; Sat, 10 Jun 2023 04:28:20 -0400 In-Reply-To: <0469e0cb-4f63-eb4b-1184-2dfeabdcf9e6@gmx.at> (message from martin rudalics on Sat, 10 Jun 2023 08:52:57 +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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263200 Archived-At: > Date: Sat, 10 Jun 2023 08:52:57 +0200 > Cc: 63967@debbugs.gnu.org > From: martin rudalics > > > diff --git a/lisp/window.el b/lisp/window.el > > index a11b1a5..6777944 100644 > > --- a/lisp/window.el > > +++ b/lisp/window.el > > @@ -8941,7 +8941,9 @@ switch-to-buffer > > "Cannot switch buffers in a dedicated window"))) > > ('pop nil) > > (_ (set-window-dedicated-p nil nil) 'force-same-window))))))) > > - (list (read-buffer-to-switch "Switch to buffer: ") nil force-same-window))) > > + (save-selected-window > > + (list > > + (read-buffer-to-switch "Switch to buffer: ") nil force-same-window)))) > > (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)) > > (set-window-start-and-point (not switch-to-buffer-obey-display-actions))) > > (cond > > That wouldn't help in all other use cases of read_minibuf where the user > will be thrown back to the minibuffer window as well. I'd rather try (the > still timid) > > -static void minibuffer_unwind (void); > +static void minibuffer_unwind (Lisp_Object); > ... > - record_unwind_protect_void (minibuffer_unwind); > + record_unwind_protect (minibuffer_unwind, selected_window); > ... > -minibuffer_unwind (void) > +minibuffer_unwind (Lisp_Object old_selected_window) > ... > + if (!EQ (old_selected_window, FRAME_SELECTED_WINDOW (f))) > + Fset_frame_selected_window (exp_MB_frame, window, Qnil); > > since the last line seems to suggest that exp_MB_frame should not be the > selected frame. 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? 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? 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?