bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer w


From: Eli Zaretskii
Subject: 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@petrofsky.org, rudalics@gmx.at, 63967@debbugs.gnu.org
> Date: Fri, 09 Jun 2023 19:09:19 +0300
> From: Eli Zaretskii <eliz@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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]