Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

> Fine.  I will push this to Emacs 27.2.

Done.  Alan, the following two concerns are still awaiting a fix:


Madhu's:

These patches introduce a regression on "graphical" emacs -

1. emacs -Q

2. M-: (setq pop-up-frames 'graphic-only)

3. M-! g <TAB>

This should pop up a *Completions* buffer in a new frame.

On choosing the completion (via a button1 or by navigating to the
desired point and typing RET) - the frame should be automatically
hidden[1]

This doesn't happen anymore and the completion buffer and frame remain
there taking up focus.


[1] default value for frame-auto-hide-function is #'iconify-frame, but
if your window manager cannot iconify it, set
(setq frame-auto-hide-function #'delete-frame)


Andrii's:

It is not producing bugs for me, but changes behavior.

E.g. in emacs -Q:

1. Evaluate
  (select-frame-set-input-focus
   (make-frame '((minibuffer . only)
                 (left . 1.0))))
2. M-x
3. C-x 5 o

Before minibuffer-follows-selected-frame, the prompt stays in the
minibuffer-only frame.
On recent master, the prompt is moved to other frame leaving
minibuffer-only frame empty.  I can't report this as a bug.  Just
wondering why minibuffer-follows-selected-frame is set to t by default,
potentially changing someone's expected behavior.


martin