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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
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: Sun, 11 Jun 2023 08:03:23 +0300

> Date: Sat, 10 Jun 2023 19:42:04 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, al <at> petrofsky.org, rudalics <at> gmx.at,
>   63967 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > I understand why we do the `set_window_buffer` and set its start and
> > point, but I can't see why we'd need to select the mini-window:
> > presumably if it needed to be (re)selected that should have been handled
> > by the window-config save&restore, no?
> 
> There was a problem with the restoring of the window configuration
> selecting a window other than the minibuffer; that is in circumstances
> where the minibuffer window should have ended up being selected.
> 
> Fset_window_configuration seems to be the troublesome function in this
> scenario.  As well as setting the window configuration, it also selects
> a window.

Where is that problem and its circumstances described?  Is there some
bug number or a discussion on emacs-devel that you could point to?

> Perhaps we should modify the minibuffer code to note which window should
> be current after the completion or abortion of the minibuffer read
> action.

Isn't that simply "the window which was selected before entering the
minibuffer"?

Previous Next

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