Q on frame focus with MS Windows

[Drew Adams]

This is driving me crazy. I've tried a zillion ways to try to work around
this problem, to no avail.

On MS Windows, whenever a new frame is created, it becomes
"selected"/"focussed". I use quote-marks here, because I think it might be
more than what Emacs calls frame selection & focus. I admit that it's
unclear to me just what's going on.

Symptoms of the newly "selected"/"focussed" frame:

1) It has the focus, in the Emacs sense of editing operations applying to
it.
2) The frame border (title bar etc.) are highlighted by the window manager.
3) The frame is raised, so it is in front of all other frames.

It is #1 that gets in my way - I'm looking for a way to get around it.

I use a standalone minibuffer frame and (setq pop-up-frames t). I have
focus-follows-mouse = nil, but I've also tried t.

Here's the problem:

1. I want to be able to open a new frame from a command that is bound in a
minibuffer map such as minibuffer-local-completion-map. The command does not
exit the minibuffer.

2. I do not want the new frame to grab the input focus. I want to be able to
continue using the minibuffer for input.

I know that Windows uses click-to-focus, and it automatically focusses a new
frame. But I'm thinking there must be some way to override this to some
extent.

I've tried every hack I can think of, from saving and restoring the selected
buffer/window/frame, to redirecting and un-redirecting the frame focus, to
playing with before-make-frame-hook and after-make-frame-functions. I cannot
get the new frame to become un-"selected"/"focussed" and let me continue to
use the minibuffer for input.

My impression is that this is not necessarily related to buffer/window/frame
selection in the Emacs sense. I say this, because I've tried to explicitly
reselect the original buffer/window/frame, and that doesn't seem to do the
trick.

It is only creating a new frame that presents this problem. For example, if
the command bound in the minibuffer map just calls display-buffer (which
doesn't select the buffer), I get the same problem: If the buffer is already
displayed in a frame, no problem; if a new frame is created, the "focus"
goes to it - I must click the minibuffer frame to get the focus back.
Otherwise, hitting a key uses the keymap (e.g. global) of the newly created
frame, rather than the minibuffer keymap.

I apologize for a rambling, not-too-clear description. If you are on
Windows, please do this, to see what I mean:

1. Put this in a file foo.el, then start emacs with runemacs.exe -q -l
"foo.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")))

2. Run `foo' during minibuffer completion. For example, `M-x [down]'.

As soon as buffer foo is created in a new frame, the focus is taken away
from the minibuffer. You can no longer type minibuffer input or hit keys
that are bound in a minibuffer map - all input goes to buffer foo.

What I'm looking for is:

1. To understand this better. Just what is the nature/cause of the problem?

2. A way (workaround) to deal with this problem - something that will keep
the input focus in the minibuffer for as long as the minibuffer is active.
(So, for instance, if done by redirect-frame-focus, I would want that undone
after the minibuffer is inactivated.)

3. If this is a bug in some sense, which could be fixed in Emacs, that would
be great. However, I also need this to work in other versions of Emacs, so I
would still want the workaround (#2).

Any help is appreciated.