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

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
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: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active
Date: Sun, 11 Jun 2023 13:40:52 +0000

Hello, Eli.

On Sun, Jun 11, 2023 at 08:03:23 +0300, Eli Zaretskii wrote:
> > 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?

I remember such a discussion vaguely, but after much searching, haven't
been able to find it again.  Sorry.

> > 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"?

Most of the time, yes.  If that window no longer exists on termination of
the minibuffer, or we've moved to a different frame, things aren't so
simple.

In read_minibuf (the meat of the minibuffer processing), there is a
variable calling_window which records that window.  It gets pushed onto
the binding stack (along with a lot of other variables) around the
recursive edit, and then possibly restored in the unwind_protect function
read_minibuf_unwind.  However, restore_window_configuration overrides it,
because of the order these things are pushed onto the binding stack by
read_minibuf.

Do you want me to fix this bug?  It seems there are quite a lot of people
who've made observations about it in the last couple of days.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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