bug#11566: 24.0.97; `read-from-minibuffer': focus to standalone minibuffer frame?

["Drew Adams" <drew.adams@oracle.com>]

> "Stacking order" and "foreground" are 2 different things.  As I wrote
> earlier, a "foreground" window/frame is the window that has focus and
> gets the keyboard input.  It doesn't have to be on the top of the
> Z-order.

Got it.

> > > (let ((old-frame (selected-frame))
> > >        (new-frame (make-frame)))
> > >    (redirect-frame-focus new-frame old-frame))
> > 
> > That puts (keeps) the input focus in old-frame.  So it 
> > seems to work as it should.
> 
> No, it keeps focus in new-frame, but makes it so the input you type at
> new-frame gets sent to old-frame.

Hm.  Maybe I'm unclear about "focus".  To me, "focus" was about input focus: the
focused frame is the one that accepts/receives keyboard input.

In something like `select-frame-set-input-focus', my interpretation was that
frame selection was related to the border highlighting and setting input focus
was related to receiving keyboard input.  AFAIK, `select-frame' does the former,
but `select-frame-set-input-focus' is needed to get the latter.

> Thus, this:
> 
> > (But new-frame has its title and border highlighted as if 
> > it had the focus.  Somehow there is a disconnect between the two.
> 
> is normal and expected behavior (AFAIU).

Expected from `redirect-frame-focus', I guess you mean.  So IIUC,
`select-frame-set-input-focus' does `select-frame' plus `redirect-frame-focus'?