completing-read (and M-x) with pop-up-frames non-nil changes frame focus

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

emacs -q
M-x set-variable pop-up-frames t
M-x complet TAB

This opens a new frame for buffer *Completions*. At least in Windows, the
new frame is selected. The frame focus for typing key sequences thus
switches to the *Completions* frame, but the minibuffer of the original
frame is still waiting for input. So, you cannot continue to type, to
disambiguate the command you want.

You can of course navigate to the command you want in *Completions* and hit
`RET' or click it with the mouse, but the minibuffer completion behavior is
completely lost - to regain it, you need to select the original frame again.

Is this a bug? I suspect, unfortunately, that the answer will be "no, that's
by design". My question then is, how can I prevent the frame focus switch to
*Completions* when I call `completing-read' or access it implicitly, via
`M-x'?

In my own, custom setup, I don't have this problem, because I have dedicated
frames for *Customize* and the minibuffer, and I use a special-display
function to display *Customize*. That function explicitly redirects the
focus from the *Customize* frame back to the minibuffer frame.

However, I want to write some code that others can use, and they will not
necessarily have a similar setup. I want users to be able to continue to
input in the original frame's minibuffer, without having to first reselect
the original frame.

Advice?


In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2005-06-26 on NONIQPC
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc
(3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../.
./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl
ude'