RE: Q on frame focus with MS Windows

[Drew Adams]

    >    >w32-focus-frame.

    >    I think there might be a race condition here.
    >    It does not work for me without `run-with-idle-timer'
    >    I believe some part of the frame creation is run asynchronously.

    >Are you using emacs -q?  I have no problem without the timer
    >and no problem with it - even using a delay of 0 sec.

    I am using emacs -Q.

Sounds like a bug.

FWIW, I don't see a problem on Windows XP SP1, with 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'

I load this file, test.el, with runemacs.exe -q --debug-init -l "test.el":

(setq pop-up-frames t
      default-frame-alist '((minibuffer))
      minibuffer-frame-alist '((minibuffer . only)))

(define-key minibuffer-local-completion-map [down] 'foo)

(defun foo () (interactive)
      (display-buffer (get-buffer-create "foo"))
      (select-frame-set-input-focus (window-frame (minibuffer-window))))

Regardless of whether foo is displayed prior to doing `M-x' and hitting
`[down]', it correctly displays "foo" and gives the standalone minibuffer
frame the focus (so subsequent uses of [next] continue to use the minibuffer
binding).