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' _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
