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: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: al <at> petrofsky.org, 63967 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active
Date: Sun, 11 Jun 2023 10:10:17 +0200

>> If w->prev_buffers gets us the right minibuffer to display here (any
>> former dw->prev_buffers = sw->prev_buffers should guarantee that), then
>> for that buffer we have to establish the corresponding start and point
>> positions.  This makes sense regardless of whether the minibuffer window
>> will be selected or not.
>
> But read_minibuf_unwind already does all that when it restores the
> window configuration, doesn't it?  Or is there something about the
> mini-window that restoring window configuration doesn't handle
> correctly?

I can imagine the following scenario: read_minibuf saves and restores up
to two window configurations - the one of the frame from where it was
invoked and the one of the frame that owned the corresponding minibuffer
window at that time.  Now with 'minibuffer-follows-selected-frame'
non-nil there might be another frame the user may want to continue the
interaction with and the configuration of that frame will not be
automatically restored upon exiting read_minibuf.  Yet, the minibuffer
window on that frame should be restored properly to show its previous
buffer, point etc.

martin

Previous Next

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