From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: Q on frame focus with MS Windows Date: Tue, 25 Oct 2005 13:33:38 -0700 Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1130272643 22473 80.91.229.2 (25 Oct 2005 20:37:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2005 20:37:23 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 22:37:14 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EUVVA-0001Rh-Id for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2005 22:34:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EUVVA-0002V6-1m for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2005 16:34:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EUVUy-0002Ur-S3 for emacs-devel@gnu.org; Tue, 25 Oct 2005 16:34:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EUVUx-0002Uf-DJ for emacs-devel@gnu.org; Tue, 25 Oct 2005 16:34:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EUVUx-0002Uc-8k for emacs-devel@gnu.org; Tue, 25 Oct 2005 16:34:19 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EUVUw-0000vI-Pk for emacs-devel@gnu.org; Tue, 25 Oct 2005 16:34:19 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9PKfmah024001 for ; Tue, 25 Oct 2005 15:42:20 -0500 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9PKXhlN001922 for ; Tue, 25 Oct 2005 14:33:43 -0600 Original-Received: from dradamslap (dhcp-amer-rmdc-csvpn-gw4-141-144-96-220.vpn.oracle.com [141.144.96.220]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id j9PKXfWr001909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 25 Oct 2005 14:33:42 -0600 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:44860 Archived-At: 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.