GNU bug report logs - #63967
28.2; switch-to-buffer in normal window fails if minibuffer window is active

Previous Next

Full log

Message #44 received at 63967 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: al <at> petrofsky.org, rudalics <at> gmx.at, monnier <at> iro.umontreal.ca,
 63967 <at> debbugs.gnu.org
Subject: Re: bug#63967: 28.2; switch-to-buffer in normal window fails if
 minibuffer window is active
Date: Sat, 10 Jun 2023 08:45:40 +0000

>> I see.  Apparently we don't work the same way.  I didn't have time to 
>> investigate this issue further after bisecting, but the first thing I 
>> would have done is to determine which of the four calls to 
>> Fset_frame_selected_window in that changeset is responsible for that 
>> bug.
>
> You assume that the only way to change the selected-window on the C 
> level is by calling Fset_frame_selected_window?  That's false; just try 
> grepping the C sources for "selected_window =".  And that's even before 
> you consider the possibilities of indirect setting, when the actual 
> setting is in Lisp via some proxy.
>

I don't think it's useful to argue, I'm just observing that we don't work 
the same way.  But no, I don't assume anything, on the contrary.  Just 
commenting out each one of the Fset_frame_selected_window in that 
changeset in turn, and checking whether doing that fixes the bug, shows 
that the culprit is the call to Fset_frame_selected_window in 
minibuffer_unwind.  Doing that does not involve any guesswork, and the 
result is 100% accurate.  Of course, that's not the end of the story, and 
of course, it could have turned out that none of these four calls is the 
culprit (in which case I would probably have checked the five calls to 
set_window_buffer).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.