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

[Eli Zaretskii <eliz@gnu.org>]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <11566@debbugs.gnu.org>
> Date: Tue, 29 May 2012 09:10:15 -0700
> 
> > > > (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.

Well, yes, but redirect-frame-focus explicitly parts them, AFAIU.

> 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.

On Windows, at least with the default setup, selecting a frame also
grabs focus.  So these two functions do the same.

> > 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.

Yes, of course.

> So IIUC, `select-frame-set-input-focus' does `select-frame' plus
> `redirect-frame-focus'?

No, it just raises the frame after selecting it and makes sure it has
focus (which in most situations it will have by virtue of being
raised).