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: prevent raising a frame from also input-focusing it Date: Sun, 30 Nov 2014 10:59:26 -0800 (PST) Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1417374022 14925 80.91.229.3 (30 Nov 2014 19:00:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2014 19:00:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 30 20:00:12 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xv9j6-0003ps-0s for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2014 20:00:08 +0100 Original-Received: from localhost ([::1]:51422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xv9j5-0002Hk-Mn for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2014 14:00:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xv9il-0002HS-2q for emacs-devel@gnu.org; Sun, 30 Nov 2014 13:59:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xv9ia-000115-HD for emacs-devel@gnu.org; Sun, 30 Nov 2014 13:59:47 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:34182) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xv9ia-00010b-AQ for emacs-devel@gnu.org; Sun, 30 Nov 2014 13:59:36 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sAUIxXNq000460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 30 Nov 2014 18:59:34 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sAUIxURf007774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 30 Nov 2014 18:59:33 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sAUIxU3f009995 for ; Sun, 30 Nov 2014 18:59:30 GMT X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:178537 Archived-At: I normally use Emacs on MS Windows. I sometimes use Emacs on GNU/Linux, but the available version there is Emacs 21 (!). I don't have any problem in either of those contexts, preventing Emacs from coupling frame raising with input-focusing the raised frame. At least I haven't noticed a problem. (I cannot connect now to the GNU/Linux machine, to check, but I think I would have noticed such a glaring problem.) On Windows I just set option `w32-grab-focus-on-raise' to nil. On GNU/Linux (Emacs 21) I don't do anything special to prevent automatic focusing of a raised frame, AFAIK. Why I haven't noticed a problem with GNU/Linux, Emacs 21, I don't know. I received a report from a user of oneonone.el, a library that (by default) creates a standalone minibuffer frame. It reports that the behavior on GNU/Emacs is always like that in Windows with non-nil `w32-grab-focus-on-raise': *raising a frame always focuses it.* Can users change this, please? (Is this possible already?) Here's a simple recipe, to show why this is unusable with a standalone minibuffer frame: emacs -Q -l "test.el" -f "test" Where test.el has this: (defun test () "" (interactive) (setq default-frame-alist (list (cons 'minibuffer nil))) (setq pop-up-frames t) (setq minibuffer-frame-alist (list (cons 'height 2) (cons 'minibuffer 'only))) (make-frame minibuffer-frame-alist) (setq minibuffer-auto-raise t)) In *scratch*, do `C-SPC'. You see message `Mark activated' in the echo area. But the input focus is switched to the minibuffer frame, away from the *scratch* frame! (That is what I see on MS Windows, with nil `w32-grab-focus-on-raise', and IIUC it is the reported behavior for GNU/Linux.) To print a message in *output* area (echo area), Emacs has also switched the *input* focus to that frame. This design makes no sense to me. It certainly makes trying to use a standalone minibuffer frame problematic. Please let me know how users can prevent this input focus switch on non-Windows platforms. Thx. Why should raising a frame be coupled with input-focusing it? Why shouldn't users be able to control this? (And why should such coupling be the default behavior?)