emacs-devel
[Top][All Lists]
Advanced

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

Re: Stop frames stealing eachothers' minibuffers!


From: Alan Mackenzie
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Sun, 1 Nov 2020 19:53:13 +0000

Hello, Eli.

On Sun, Nov 01, 2020 at 20:35:54 +0200, Eli Zaretskii wrote:
> > Date: Sat, 31 Oct 2020 20:39:14 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > How about emptying mini-windows which don't have live minibuffers
> > > > on them?  This could be tested by Fminibufferp (b, Qt).  In
> > > > practice, when minibuffer-follows-selected-frame this would empty
> > > > all mini-windows but the current one, and when !m-f-s-f it would
> > > > leave intact the mini-windows we want to be left intact.

> > > let me turn the table and ask why this hunk is needed?  What
> > > doesn't work right if this code is left in place?

> > Without that hunk (i.e. with the emptying-out code):
> > (i) emacs -Q
> > (ii) M-: (setq minibuffer-follows-selected-frame nil)
> > (iii) C-x 5 2 ; giving two frames.
> > (iv) C-x b ; leaving a minibuffer open.
> > (v) C-x 5 o ; move to other frame.

> > (vi) C-r in ; start an isearch.
> > (vii) C-x 8 RET ; intending on inserting a non-keyboard character.

> > At this point, the mini-window in Frame 1 is emptied.  This is bad.

> But the same happens with the current master.  So this is no worse than
> what we have today.

It might be no worse (the situations aren't exactly parallel), but I
think the !minibuffer_f_s_frame case should be no worse than the m_f_s_f
case.  We should be aiming to improve things.  The mental model for
!m_f_s_f is that a minibuffer is attached to a frame.  So actions in a
different frame shouldn't affect it.

> > By contrast, the same sequence of operations without (ii) (with an extra
> > step:

> > (v).5 C-x o ; move to the ordinary window.

> > ), the first minibuffer is "protected" on Frame 2 underneath the C-x 8
> > RET minibuffer.  So, when the isearch is finished, the "Switch to
> > buffer" minibuffer appears again, and is active.

> Is this with or without removing the code which empties all the other
> minibuffers?

This is with the emptying code present, exactly as in the previous case.


I propose amending the emptying out code to look like this:

  /* Empty out the minibuffers of all frames, except those frames
     where there is an active minibuffer.
     Set them to point to ` *Minibuf-0*', which is always empty.  */
  empty_minibuf = get_minibuffer (0);

  FOR_EACH_FRAME (dummy, frame)
    {
      Lisp_Object root_window = Fframe_root_window (frame);
      Lisp_Object mini_window = XWINDOW (root_window)->next;
      Lisp_Object buffer;

      if (!NILP (mini_window) && !EQ (mini_window, minibuf_window)
          && !NILP (Fwindow_minibuffer_p (mini_window)))
        {
          buffer = XWINDOW (mini_window)->contents;
          if (NILP (Fminibufferp (buffer, Qt)))       <========================
            /* Use set_window_buffer instead of Fset_window_buffer (see
               discussion of bug#11984, bug#12025, bug#12026).  */
            set_window_buffer (mini_window, empty_minibuf, 0, 0);
        }
    }

Here Fminibufferp (with the new argument Qt) tests for an active
minibuffer.  This code appears to work well.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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