Re: Stop frames stealing eachothers' minibuffers!

[Andrii Kolomoiets <andreyk.mad@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]


In GNU Emacs 28.0.50 (build 24, x86_64-apple-darwin19.6.0, NS
appkit-2022.10 Version 11.0.1 (Build 20B29))
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.0.1

> Thanks.  To elaborate on an earlier problem I mentioned which, as I
> found out, happens already with Emacs 27 at the least.  I'd be just
> interested if you can reproduce it on your system.  Start with
>
> emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

To make both frames visible I use the following command:

emacs -Q --eval "(setq initial-frame-alist '((minibuffer) (top . 86)))"

> Now in the minibuffer window type C-h f and at the prompt type setq RET.
> This pops up a help window on the normal frame explaining 'setq' and
> 'Type "q" in help window to delete it.' appears in the minibuffer
> window.  Here, sometimes the normal frame is selected, sometimes the
> minibuffer frame remains selected.  It might be a timing issue since
> sometimes I see the cursor flicker at the end of the 'Type "q" ...'
> text before it moves to the normal frame, provided it moves there.

Here the normal frame is visually selected, but the minibuffer frame is
ready to receive input.  See attached screenshot.

> The strange thing that happens is when I now type "q" in the help
> window.  Here the minibuffer window gets selected and ready to receive
> input but no cursor is shown in it.  Do you see that?  Anyone else?

Can confirm.


[-- Attachment #2: chf.png --]
[-- Type: image/png, Size: 114767 bytes --]