From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: prevent raising a frame from also input-focusing it Date: Sun, 30 Nov 2014 15:48:03 -0800 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1417391318 11801 80.91.229.3 (30 Nov 2014 23:48:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2014 23:48:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 01 00:48:29 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 1XvEE8-000214-7x for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 00:48:28 +0100 Original-Received: from localhost ([::1]:52200 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvEE7-0002MF-Sk for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2014 18:48:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvEDr-0002M5-8d for emacs-devel@gnu.org; Sun, 30 Nov 2014 18:48:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvEDm-0003Ve-6Z for emacs-devel@gnu.org; Sun, 30 Nov 2014 18:48:11 -0500 Original-Received: from mail-pa0-x22a.google.com ([2607:f8b0:400e:c03::22a]:63240) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvEDl-0003Va-Vg for emacs-devel@gnu.org; Sun, 30 Nov 2014 18:48:06 -0500 Original-Received: by mail-pa0-f42.google.com with SMTP id et14so9912956pad.1 for ; Sun, 30 Nov 2014 15:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Wt0vQmKGgeONkxmjmCvw5zq8FJarKuLbPIOBZsx/GuU=; b=CUEqA3APk0OJQs7pa6kTjcbafFQv4YZOLj9x5CETJyp7YeTVdd+LSHpauDxz6u0VjW rgJzPhhxSpfsjFljX1aEeTEEKIlEGJagwxu91N3U0CGu27uydgBnsQ55CPBQqS0Bq2/8 H7e9ISNSCKR4kmEx1pjwMCO+RR2akLS43pqwRwAQ4GwG6MFJTc7RgSryM8d5mLw0Kwq3 WdAwaXLAzeAq9G7mywC0ZK3ejK3R76gOfAUNxxkbEnMPxRnAIk16KNWl8q+4bdJhio2S HuUTlKjGaf+PVZYCmmGGYfcf44MhWSLOgTG9Ho9OwtzoJkBV8krmZKP5f4srS7eQONMv Z8cA== X-Received: by 10.66.66.40 with SMTP id c8mr95844953pat.66.1417391285054; Sun, 30 Nov 2014 15:48:05 -0800 (PST) Original-Received: from [10.0.1.37] (75-165-99-219.tukw.qwest.net. [75.165.99.219]) by mx.google.com with ESMTPSA id my1sm15756285pbc.20.2014.11.30.15.48.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Nov 2014 15:48:04 -0800 (PST) X-Priority: 3 In-Reply-To: X-Mailer: Apple Mail (2.1993) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::22a 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:178552 Archived-At: This is largely a function of the user's window manager (of which there are dozens in active use), not emacs. The reason that you haven't noticed it under MSWindows is that you (mostly) don't get a choice of window managers there. Presumably, whatever wm you're using under GNU/Linux (which might be controlled by your MSWindows machine, for example if you're using an MSWindows X Server) uses the behavior you like by default. Focus-on-raise is the default behavior of many window managers. How to change it depends entirely on the wm in question. Hope that helps, ~Chad > On 30 Nov 2014, at 10:59, Drew Adams wrote: > > 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?) >