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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Alan Mackenzie <acm <at> muc.de>
Cc: al <at> petrofsky.org, rudalics <at> gmx.at, 63967 <at> debbugs.gnu.org
Subject: Re: bug#63967: 28.2;
 switch-to-buffer in normal window fails if minibuffer window is active
Date: Fri, 09 Jun 2023 22:18:08 +0300

> Cc: al <at> petrofsky.org, rudalics <at> gmx.at, 63967 <at> debbugs.gnu.org
> Date: Fri, 09 Jun 2023 19:09:19 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > And if it happens with `read-buffer-to-switch` I can't see any reason
> > why it wouldn't happen for most/all other uses of the minibuffer.
> 
> It probably does, yes.

AFAICT, the clobbering of the selected window happens in
minibuffer_unwind:

  static void
  minibuffer_unwind (void)
  {
    struct frame *f;
    struct window *w;
    Lisp_Object window;
    Lisp_Object entry;

    if (NILP (exp_MB_frame)) return; /* "Can't happen." */
    f = XFRAME (exp_MB_frame);
    window = f->minibuffer_window;
    w = XWINDOW (window);
    if (FRAME_LIVE_P (f))
      {
	/* minibuf_window = sf->minibuffer_window; */
	if (!NILP (w->prev_buffers))
	  {
	    entry = Fcar (w->prev_buffers);
	    w->prev_buffers = Fcdr (w->prev_buffers);
	    set_window_buffer (window, Fcar (entry), 0, 0);
	    Fset_window_start (window, Fcar (Fcdr (entry)), Qnil);
	    Fset_window_point (window, Fcar (Fcdr (Fcdr (entry))));
	    /* set-window-configuration may/will have unselected the
	       mini-window as the selected window.  Restore it. */
	    Fset_frame_selected_window (exp_MB_frame, window, Qnil);  <<<<<<<<<
	  }
	else
	  set_window_buffer (window, nth_minibuffer (0), 0, 0);
      }
  }

And since minibuffer_unwind is called _after_
restore_window_configuration, it overwrites what the latter does.

Why minibuffer_unwind doesn't test some condition which would tell it
at all has to do something, I don't know.  It seems to think that the
frame exp_MB_frame is still live and that its "expired" minibuffer
needs to be replaced? why?  Is the logic inside read_minibuf_unwind
flawed in the case that enable_recursive_minibuffers is non-zero?

Previous Next

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