From unknown Fri Aug 08 22:14:43 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#58343 <58343@debbugs.gnu.org> To: bug#58343 <58343@debbugs.gnu.org> Subject: Status: 29.0.50; ELisp code run in "inconsitent" selected-window state Reply-To: bug#58343 <58343@debbugs.gnu.org> Date: Sat, 09 Aug 2025 05:14:43 +0000 retitle 58343 29.0.50; ELisp code run in "inconsitent" selected-window state reassign 58343 emacs submitter 58343 Stefan Monnier severity 58343 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 06 20:06:46 2022 Received: (at submit) by debbugs.gnu.org; 7 Oct 2022 00:06:46 +0000 Received: from localhost ([127.0.0.1]:33852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogat3-0001jN-JL for submit@debbugs.gnu.org; Thu, 06 Oct 2022 20:06:46 -0400 Received: from lists.gnu.org ([209.51.188.17]:53906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogasz-0001j6-25 for submit@debbugs.gnu.org; Thu, 06 Oct 2022 20:06:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49216) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogasy-0000Ej-42 for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 20:06:40 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31233) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogasv-0002XQ-5N for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 20:06:39 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5D2C2100142; Thu, 6 Oct 2022 20:06:34 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 55028100091; Thu, 6 Oct 2022 20:06:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1665101192; bh=qDjeLU8aXe44UFrY8YfWs1gp1wErj/+vR5ThiBiuoSw=; h=From:To:Subject:Date:From; b=H8/N28OgF/x5Zzl070q9rERvk8NTF/6Jt6fPlHD4Wa4k3iOJocN1oI1ol7SCHKqZw KX2xTi2G636HpUB5Fl2NzZ2ePFfRpw/tVlQ/Z7QAelxxTZdviXTMpgZfL6LgmdNAZG sjhNgqGsa0PbxIMevJ4EwsI8FONl0WGR653cyPsOZ994coz6DPH3jRe+7EqNF0yB8u yDZjqqZ6ttX1F2EqxCVs/dg3zbDA4axGQpDAyXOjzz0u/r6VgSMjWX454qsd/tXQTA WiDg1DPTYz/7TlLbXK3Wt4ffQgOv6tgtmLDo52b9cptbsaBjRxAmpUssZEOQMHbeON PLz5WIjiTBNOg== Received: from milanesa (65-110-220-202.cpe.pppoe.ca [65.110.220.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 20F8A120CE9; Thu, 6 Oct 2022 20:06:32 -0400 (EDT) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: 29.0.50; ELisp code run in "inconsitent" selected-window state Message-ID: X-Debbugs-Cc: Alan Mackenzie Date: Thu, 06 Oct 2022 20:06:25 -0400 MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.058 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Package: Emacs Version: 29.0.50 Hi Alan and friends, In commit dfa3e6f424b20fe27d9041b2ce7d69811df5d8cd, Alan added the following code to do_switch_frame: diff --git a/src/frame.c b/src/frame.c index ccac18d23c2..dc8045f41e6 100644 --- a/src/frame.c +++ b/src/frame.c @@ -1564,6 +1564,13 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor if (! FRAME_MINIBUF_ONLY_P (XFRAME (selected_frame))) last_nonminibuf_frame = XFRAME (selected_frame); + /* If the selected window in the target frame is its mini-window, we move + to a different window, the most recently used one, unless there is a + valid active minibuffer in the mini-window. */ + if (EQ (f->selected_window, f->minibuffer_window) + && NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt))) + Fset_frame_selected_window (frame, call1 (Qget_mru_window, frame), Qnil); + Fselect_window (f->selected_window, norecord); /* We want to make sure that the next event generates a frame-switch the problem with this is that it calls `Qget_mru_window` which is ELisp code, and that we're in the very middle of changing the selected frame, so we have already changed the `selected-frame` variable a few lines earlier, but the select-window has not yet been adjusted accordingly. Running ELisp code in a state where (selected-window) and (frame-selected-window) aren't equal is a recipe for problems. I have already wasted many hours in the past tracking down bugs linked to this kind of situation (back when the mode-line was processed in such an inconsistent state, for example), and I really don't want to go there. So we should arrange to run this `get-mru-window` function at some other time, for example a few lines earlier before we set `selected-frame`. I don't understand this code nearly enough to know how to move the code, because it probably interacts with the other statements in non-trivial ways, so the patch below is just a naive suggestion (it seems to work here without triggering my many sprinkled assertions checking that `EQ (XFRAME (selected_frame)->selected_window, selected_window)`, but it's a far cry from a confirmation that it's right). Hopefully someone here is aware of some of the potential pitfalls. Stefan diff --git a/src/frame.c b/src/frame.c index 91b9bec82c3..58b6ee50d23 100644 --- a/src/frame.c +++ b/src/frame.c @@ -1503,18 +1503,8 @@ do_switch_frame (Lisp_Object frame, int for_deletion, Lisp_Object norecord) sf->select_mini_window_flag = MINI_WINDOW_P (XWINDOW (sf->selected_window)); - selected_frame = frame; - move_minibuffers_onto_frame (sf, for_deletion); - if (f->select_mini_window_flag - && !NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt))) - f->selected_window = f->minibuffer_window; - f->select_mini_window_flag = false; - - if (! FRAME_MINIBUF_ONLY_P (XFRAME (selected_frame))) - last_nonminibuf_frame = XFRAME (selected_frame); - /* If the selected window in the target frame is its mini-window, we move to a different window, the most recently used one, unless there is a valid active minibuffer in the mini-window. */ @@ -1528,6 +1518,16 @@ do_switch_frame (Lisp_Object frame, int for_deletion, Lisp_Object norecord) Fset_frame_selected_window (frame, w, Qnil); } + selected_frame = frame; + + if (f->select_mini_window_flag + && !NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt))) + f->selected_window = f->minibuffer_window; + f->select_mini_window_flag = false; + + if (! FRAME_MINIBUF_ONLY_P (XFRAME (selected_frame))) + last_nonminibuf_frame = XFRAME (selected_frame); + Fselect_window (f->selected_window, norecord); /* We want to make sure that the next event generates a frame-switch From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 14:08:56 2022 Received: (at 58343) by debbugs.gnu.org; 12 Oct 2022 18:08:57 +0000 Received: from localhost ([127.0.0.1]:58400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oigA4-0004tt-Ep for submit@debbugs.gnu.org; Wed, 12 Oct 2022 14:08:56 -0400 Received: from mx3.muc.de ([193.149.48.5]:57745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oigA2-0004tf-Pg for 58343@debbugs.gnu.org; Wed, 12 Oct 2022 14:08:55 -0400 Received: (qmail 48875 invoked by uid 3782); 12 Oct 2022 20:08:48 +0200 Received: from acm.muc.de (p4fe15af2.dip0.t-ipconnect.de [79.225.90.242]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 12 Oct 2022 20:08:47 +0200 Received: (qmail 12215 invoked by uid 1000); 12 Oct 2022 18:08:47 -0000 Date: Wed, 12 Oct 2022 18:08:47 +0000 To: Stefan Monnier Subject: Re: bug#58343: 29.0.50; ELisp code run in "inconsitent" selected-window state Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58343 Cc: 58343@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Thu, Oct 06, 2022 at 20:06:25 -0400, Stefan Monnier wrote: > Package: Emacs > Version: 29.0.50 > Hi Alan and friends, > In commit dfa3e6f424b20fe27d9041b2ce7d69811df5d8cd, Alan added the > following code to do_switch_frame: > diff --git a/src/frame.c b/src/frame.c > index ccac18d23c2..dc8045f41e6 100644 > --- a/src/frame.c > +++ b/src/frame.c > @@ -1564,6 +1564,13 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor > if (! FRAME_MINIBUF_ONLY_P (XFRAME (selected_frame))) > last_nonminibuf_frame = XFRAME (selected_frame); > + /* If the selected window in the target frame is its mini-window, we move > + to a different window, the most recently used one, unless there is a > + valid active minibuffer in the mini-window. */ > + if (EQ (f->selected_window, f->minibuffer_window) > + && NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt))) > + Fset_frame_selected_window (frame, call1 (Qget_mru_window, frame), Qnil); > + > Fselect_window (f->selected_window, norecord); > /* We want to make sure that the next event generates a frame-switch > the problem with this is that it calls `Qget_mru_window` which is ELisp > code, and that we're in the very middle of changing the selected frame, > so we have already changed the `selected-frame` variable a few lines > earlier, but the select-window has not yet been adjusted accordingly. > Running ELisp code in a state where (selected-window) and > (frame-selected-window) aren't equal is a recipe for problems. I have > already wasted many hours in the past tracking down bugs linked to this > kind of situation (back when the mode-line was processed in such an > inconsistent state, for example), and I really don't want to go there. > So we should arrange to run this `get-mru-window` function at some other > time, for example a few lines earlier before we set `selected-frame`. > I don't understand this code nearly enough to know how to move the code, > because it probably interacts with the other statements in non-trivial > ways, so the patch below is just a naive suggestion (it seems to work > here without triggering my many sprinkled assertions checking that > `EQ (XFRAME (selected_frame)->selected_window, selected_window)`, > but it's a far cry from a confirmation that it's right). > Hopefully someone here is aware of some of the potential pitfalls. One minor problem I see at the moment is that the call to move_minibuffers_onto_frame wasn't moved together with the surrounding code. With its current calling convention, it needs to be called _after_ selected_frame has been set, because it uses selected_frame. Is there any reason this function call was left where it was? Or could it just be moved, too? Otherwise, its calling convention will need to be adapted. Other than that, I haven't seen any problems as yet, though I admit I haven't tried it out. > Stefan [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 14:35:48 2022 Received: (at 58343) by debbugs.gnu.org; 12 Oct 2022 18:35:48 +0000 Received: from localhost ([127.0.0.1]:58433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oiga3-0007ma-Ix for submit@debbugs.gnu.org; Wed, 12 Oct 2022 14:35:48 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oiga1-0007mM-DP for 58343@debbugs.gnu.org; Wed, 12 Oct 2022 14:35:46 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7DC7A1001D0; Wed, 12 Oct 2022 14:35:39 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DA04C1000FC; Wed, 12 Oct 2022 14:35:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1665599736; bh=Uc/ZQJDU0qO+W9fwROAyKFf84EYPwKqliRzjR+0fFLA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bp1CtfugkKeImYCd1Wj4r9EtA9LfU2Gb8Gqv5QbOx9wn4udRm8aLNg6+Sqnz86A6l jyt4zcvt98FKh+nC3nI+3VY9wCtAF7c4HzVpkmGyxIf3Rx/7Hb3KYI/ga9LAYkgz8k 1x/3Qanv2b6Uz4FtoYZu6PJcT4WIwppUfJwQuaYzdaldz3DDyzkzu8TyHooLQhg6PT AfAUjSnxZNDrUgxliZI57tgBKUiPxMUMO7o42hfdAKBSF0gIQX7dGvjosxyTmevXe9 fYv9lJTBpoBMBp6OIX+GPnolDNC3A5bvlHQWqR2MTHYG/ZuKuDvNWyeSx5JDlBpMHM Yb+FHOG6YDiug== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A6EFC1208E2; Wed, 12 Oct 2022 14:35:36 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#58343: 29.0.50; ELisp code run in "inconsitent" selected-window state In-Reply-To: (Alan Mackenzie's message of "Wed, 12 Oct 2022 18:08:47 +0000") Message-ID: References: Date: Wed, 12 Oct 2022 14:35:33 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.163 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58343 Cc: 58343@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Alan, > One minor problem I see at the moment is that the call to > move_minibuffers_onto_frame wasn't moved together with the surrounding > code. With its current calling convention, it needs to be called > _after_ selected_frame has been set, because it uses selected_frame. Aha! > Is there any reason this function call was left where it was? I was afraid that swapping `move_minibuffers_onto_frame` and if (EQ (f->selected_window, f->minibuffer_window) /* The following test might fail if the mini-window contains a non-active minibuffer. */ && NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt))) { Lisp_Object w = call1 (Qget_mru_window, frame); if (WINDOW_LIVE_P (w)) /* W can be nil in minibuffer-only frames. */ Fset_frame_selected_window (frame, w, Qnil); } would not result in the same final result, e.g. because the name "move_minibuffers_onto_frame" suggests it might change the result of `XWINDOW (f->minibuffer_window)->contents`. > Or could it just be moved, too? Otherwise, its calling convention > will need to be adapted. The patch below refrains from moving it and passes it the to-be-selected frame as argument instead. Stefan diff --git a/src/frame.c b/src/frame.c index 91b9bec82c3..24de0701d13 100644 --- a/src/frame.c +++ b/src/frame.c @@ -1503,17 +1503,7 @@ do_switch_frame (Lisp_Object frame, int for_deletion, Lisp_Object norecord) sf->select_mini_window_flag = MINI_WINDOW_P (XWINDOW (sf->selected_window)); - selected_frame = frame; - - move_minibuffers_onto_frame (sf, for_deletion); - - if (f->select_mini_window_flag - && !NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt))) - f->selected_window = f->minibuffer_window; - f->select_mini_window_flag = false; - - if (! FRAME_MINIBUF_ONLY_P (XFRAME (selected_frame))) - last_nonminibuf_frame = XFRAME (selected_frame); + move_minibuffers_onto_frame (sf, frame, for_deletion); /* If the selected window in the target frame is its mini-window, we move to a different window, the most recently used one, unless there is a @@ -1528,6 +1518,16 @@ do_switch_frame (Lisp_Object frame, int for_deletion, Lisp_Object norecord) Fset_frame_selected_window (frame, w, Qnil); } + selected_frame = frame; + + if (f->select_mini_window_flag + && !NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt))) + f->selected_window = f->minibuffer_window; + f->select_mini_window_flag = false; + + if (! FRAME_MINIBUF_ONLY_P (XFRAME (selected_frame))) + last_nonminibuf_frame = XFRAME (selected_frame); + Fselect_window (f->selected_window, norecord); /* We want to make sure that the next event generates a frame-switch @@ -2110,7 +2110,7 @@ delete_frame (Lisp_Object frame, Lisp_Object force) else /* Ensure any minibuffers on FRAME are moved onto the selected frame. */ - move_minibuffers_onto_frame (f, true); + move_minibuffers_onto_frame (f, selected_frame, true); /* Don't let echo_area_window to remain on a deleted frame. */ if (EQ (f->minibuffer_window, echo_area_window)) diff --git a/src/lisp.h b/src/lisp.h index 56f24d82810..5f6721595c0 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -4792,7 +4792,7 @@ fast_string_match_ignore_case (Lisp_Object regexp, Lisp_Object string) extern Lisp_Object Vminibuffer_list; extern Lisp_Object last_minibuf_string; -extern void move_minibuffers_onto_frame (struct frame *, bool); +extern void move_minibuffers_onto_frame (struct frame *, Lisp_Object, bool); extern bool is_minibuffer (EMACS_INT, Lisp_Object); extern EMACS_INT this_minibuffer_depth (Lisp_Object); extern EMACS_INT minibuf_level; diff --git a/src/minibuf.c b/src/minibuf.c index bedc5644807..aebd17c0b76 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -187,13 +187,15 @@ zip_minibuffer_stacks (Lisp_Object dest_window, Lisp_Object source_window) /* If `minibuffer_follows_selected_frame' is t, or we're about to delete a frame which potentially "contains" minibuffers, move them - from the old frame to the selected frame. This function is + from the old frame to the to-be-selected frame. This function is intended to be called from `do_switch_frame' in frame.c. OF is the - old frame, FOR_DELETION is true if OF is about to be deleted. */ + old frame, SF is the to-be-selected frame, and FOR_DELETION is true + if OF is about to be deleted. */ void -move_minibuffers_onto_frame (struct frame *of, bool for_deletion) +move_minibuffers_onto_frame (struct frame *of, Lisp_Object sf, + bool for_deletion) { - struct frame *f = XFRAME (selected_frame); + struct frame *f = XFRAME (sf); minibuf_window = f->minibuffer_window; if (!(minibuf_level @@ -206,7 +208,7 @@ move_minibuffers_onto_frame (struct frame *of, bool for_deletion) { zip_minibuffer_stacks (f->minibuffer_window, of->minibuffer_window); if (for_deletion && XFRAME (MB_frame) != of) - MB_frame = selected_frame; + MB_frame = sf; } } From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 15:14:00 2022 Received: (at 58343) by debbugs.gnu.org; 12 Oct 2022 19:14:00 +0000 Received: from localhost ([127.0.0.1]:58455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oihB2-0000H7-01 for submit@debbugs.gnu.org; Wed, 12 Oct 2022 15:14:00 -0400 Received: from mx3.muc.de ([193.149.48.5]:59816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oihB0-0000Gv-VH for 58343@debbugs.gnu.org; Wed, 12 Oct 2022 15:13:59 -0400 Received: (qmail 7959 invoked by uid 3782); 12 Oct 2022 21:13:52 +0200 Received: from acm.muc.de (p4fe15af2.dip0.t-ipconnect.de [79.225.90.242]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 12 Oct 2022 21:13:51 +0200 Received: (qmail 12590 invoked by uid 1000); 12 Oct 2022 19:13:51 -0000 Date: Wed, 12 Oct 2022 19:13:51 +0000 To: Stefan Monnier Subject: Re: bug#58343: 29.0.50; ELisp code run in "inconsitent" selected-window state Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58343 Cc: acm@muc.de, 58343@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Wed, Oct 12, 2022 at 14:35:33 -0400, Stefan Monnier wrote: > Hi Alan, > > One minor problem I see at the moment is that the call to > > move_minibuffers_onto_frame wasn't moved together with the surrounding > > code. With its current calling convention, it needs to be called > > _after_ selected_frame has been set, because it uses selected_frame. > Aha! > > Is there any reason this function call was left where it was? > I was afraid that swapping `move_minibuffers_onto_frame` and > if (EQ (f->selected_window, f->minibuffer_window) > /* The following test might fail if the mini-window contains a > non-active minibuffer. */ > && NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt))) > { > Lisp_Object w = call1 (Qget_mru_window, frame); > if (WINDOW_LIVE_P (w)) /* W can be nil in minibuffer-only frames. */ > Fset_frame_selected_window (frame, w, Qnil); > } > would not result in the same final result, e.g. because the name > "move_minibuffers_onto_frame" suggests it might change the result of > `XWINDOW (f->minibuffer_window)->contents`. Yes, I suppose you're right. > > Or could it just be moved, too? Otherwise, its calling convention > > will need to be adapted. > The patch below refrains from moving it and passes it the to-be-selected > frame as argument instead. Yes. That's a better solution than moving the function call around, particularly given that there're are only two calls to it, both in frame.c. Just one small thing: the name sf is a bad name for a Lisp_Object - there's a de facto convention in minibuf.c and frame.c that f, sf, and of, etc are struct *frame's, and selected_frame, frame, etc., are Lisp_Object's which are frames. In fact sf is used as a struct *frame elsewhere in minibuf.c. Let me guess - originally this sf was a struct *frame, but got changed to a Lisp_Object when it became clear that it was needed to set MB_frame with. ;-) > Stefan [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 12 17:07:15 2022 Received: (at 58343) by debbugs.gnu.org; 12 Oct 2022 21:07:15 +0000 Received: from localhost ([127.0.0.1]:58539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oiiwc-0007T8-Oe for submit@debbugs.gnu.org; Wed, 12 Oct 2022 17:07:14 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oiiwb-0007Sw-B3 for 58343@debbugs.gnu.org; Wed, 12 Oct 2022 17:07:13 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 825EC80411; Wed, 12 Oct 2022 17:07:07 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D104C80091; Wed, 12 Oct 2022 17:07:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1665608825; bh=l5Eb3QdAQkfsFLoTvl8oqObQREPQkQs5gn5K8jgtGCk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LJnC7ZoIVcWznb5DwZrhRZCxNrqM26kgYrK2azR68uWDUXKC7tv3mp+gEjxy+hcl+ 2zaKv+bRIzkjYQg3QfUk7+89u8qFZi5PG/4V7lc2Mot0R5ajLVXiHJ0NXgo2Q7lW4M t8CUNZBap2zyuLnPKNp7Al+iGNxueEMaxz/ViIJk+wBJKpZawa68ip9BVlQILEhFBn /tPtM09aBLCFhrJQOQIaKO0BsKLiMVo7lt56qbtutVV80bo2D/YbXFQHdZg9FGNpFV iwteO30Joecp1M2YFgfKzIBGlAiCH2MuECQbtILJc6kfKco6xGRz4N/wU4oux3QfDh VMbw9uF5nHkNQ== Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BE9871201B6; Wed, 12 Oct 2022 17:07:05 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#58343: 29.0.50; ELisp code run in "inconsitent" selected-window state In-Reply-To: (Alan Mackenzie's message of "Wed, 12 Oct 2022 19:13:51 +0000") Message-ID: References: Date: Wed, 12 Oct 2022 17:07:04 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.178 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58343 Cc: 58343@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Just one small thing: the name sf is a bad name for a Lisp_Object - Very good point, thanks. > Let me guess - originally this sf was a struct *frame, but got changed > to a Lisp_Object when it became clear that it was needed to set MB_frame > with. ;-) Did you install a camera in my office? I pushed the updated code, thank you, Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 05 13:10:01 2023 Received: (at control) by debbugs.gnu.org; 5 Sep 2023 17:10:01 +0000 Received: from localhost ([127.0.0.1]:58796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdZYv-0003uL-9X for submit@debbugs.gnu.org; Tue, 05 Sep 2023 13:10:01 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33048) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdZYs-0003u5-Fu for control@debbugs.gnu.org; Tue, 05 Sep 2023 13:09:59 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 799EA8024B; Tue, 5 Sep 2023 13:09:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1693933791; bh=i6wt7ih0V79GQlcOyqYLpnEqQeHxJ41LM4Dw3JlnMa8=; h=From:To:Subject:Date:From; b=D70LuifZyq4aDwum0FD6Uk2vyDN50vWHoEwjLXjQpzfem5luJvjGn7KLfBqyw53ai hYDCGFcCWXUly/k4TdKsIMciAh+bbk/ObwwhHP75q9v3Zw2eHY12N6e20xxd8WQf+2 TYhh3eoAUc6v7r7ckOqW+o2wFru9cyfJfysjDZTtCYYHK85vTUvAuNOaLPq/daXRHK A5CLNIxiyjiYN2UD9METMU7du3d+vfEmk5U+hvsYvvge+tRZzPdIRk6a56gFAZyAh3 rA0ZBd3U4YXZFggW2v3Dyi0zsdoCr2vLcA962jT5ok7/Uel1V+cxjT7DuwPhZBSStv 9XVjr/4/IQO+Q== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7999D802DA; Tue, 5 Sep 2023 13:09:51 -0400 (EDT) Received: from pastel (69-165-136-223.dsl.teksavvy.com [69.165.136.223]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 53F4B1201C6; Tue, 5 Sep 2023 13:09:51 -0400 (EDT) From: Stefan Monnier To: control@debbugs.gnu.org Subject: Re: bug#58343: 29.0.50; ELisp code run in "inconsitent" Message-ID: Date: Tue, 05 Sep 2023 13:09:50 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.032 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 58343 From unknown Fri Aug 08 22:14:43 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 04 Oct 2023 11:24:21 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator