From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#745: pop-to-buffer, frames, and input focus Date: Wed, 27 Aug 2008 10:12:19 +0200 Message-ID: <48B50C63.8010402@gmx.at> References: <48AC2F4A.1000507@gmx.at> <48AC851A.3020906@gmx.at> <48AD2FB5.3000204@gmx.at> <48ADD085.50505@gmx.at> <48AEEBB8.50201@gmx.at> <48AFFD26.3040204@gmx.at> <48B2B78C.9090407@gmx.at> Reply-To: martin rudalics , 745@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1219825667 16661 80.91.229.12 (27 Aug 2008 08:27:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Aug 2008 08:27:47 +0000 (UTC) Cc: 745@emacsbugs.donarmstrong.com To: Helmut Eller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 27 10:28:40 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KYGON-00078a-QB for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Aug 2008 10:28:40 +0200 Original-Received: from localhost ([127.0.0.1]:56076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYGNP-0002hZ-8j for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Aug 2008 04:27:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KYGNK-0002gQ-Jx for bug-gnu-emacs@gnu.org; Wed, 27 Aug 2008 04:27:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KYGNH-0002eA-NR for bug-gnu-emacs@gnu.org; Wed, 27 Aug 2008 04:27:34 -0400 Original-Received: from [199.232.76.173] (port=38946 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYGNH-0002dp-I9 for bug-gnu-emacs@gnu.org; Wed, 27 Aug 2008 04:27:31 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:45415) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KYGNG-0007Iv-I4 for bug-gnu-emacs@gnu.org; Wed, 27 Aug 2008 04:27:31 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m7R8RS3H002839; Wed, 27 Aug 2008 01:27:29 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m7R8P6tE001712; Wed, 27 Aug 2008 01:25:06 -0700 X-Loop: don@donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 27 Aug 2008 08:25:05 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 745 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 745-submit@emacsbugs.donarmstrong.com id=B745.121982495232031 (code B ref 745); Wed, 27 Aug 2008 08:25:05 +0000 Original-Received: (at 745) by emacsbugs.donarmstrong.com; 27 Aug 2008 08:15:52 +0000 Original-Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id m7R8FlNO032024 for <745@emacsbugs.donarmstrong.com>; Wed, 27 Aug 2008 01:15:49 -0700 Original-Received: (qmail invoked by alias); 27 Aug 2008 08:15:41 -0000 Original-Received: from 62-47-63-62.adsl.highway.telekom.at (EHLO [62.47.63.62]) [62.47.63.62] by mail.gmx.net (mp048) with SMTP; 27 Aug 2008 10:15:41 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+sF4JOsISs866hpSeBRU93pN1sFlMIUTnKnVFku9 czmPfCNZtPyh1y User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Wed, 27 Aug 2008 04:27:34 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:19755 Archived-At: >> So when `display-buffer' has called `pop-up-frame-function' we always >> anticipate that the new frame is mapped (visible), has got input focus, >> and is raised. [...] > In other words, we don't even know that the frame is mapped!] > > However, even documenting that the input focus is unspecified would be > of some use. Yes. Nevertheless, the idea that we "anticipate" the window manager to do all these things is valid I presume - even it we don't "know" whether the frame is visible in the first place. >> IIUC we currently rely on the window-manager to >> raise and focus the frame. > > Currently Emacs does both. Requesting the focus from the X server > (XSetInputFocus) and telling the window manager to activate > (x_ewmh_activate_frame [which for most WMs is focus+raise]) the frame. I suppose we do both just because up to Emacs 22 we used XSetInputFocus exclusively and maybe some window managers won't handle EWMHs yet (or won't handle them in the sense of Emacs). Should we, in your opinion make this customizable? That is, an option `frame-activate-method' which if nil does both (as now), if 'explicit does XSetInputFocus only, and if 'implicit does x_ewmh_activate_frame only?. > I guess the usual sequence of events is this: > > 1. Emacs tries to map a frame and waits for notification > 2. WM intercepts map request > 3. WM maps the frame + gives focus to frame + raises frame > 4. Emacs receives MapNotify > > If we add a fifth step: > > 5. Emacs requests focus and informs WM to activate the frame .... without waiting for a FocusIn event? > we probably do something twice, but activating the same frame twice > shouldn't hurt. We have a problem if the WM decides to activate a > different frame, but that seems unlikely. IIRC window managers relying on EWMHs do not like explicit focus and raise frame requests. They might do something with such requests but this something could be quite unpredictable. I also STR that people reported some flickering with two subsequent raise or focus requests. Hence, once again: Should we try - with the help of an option - do this either the old-style way without calling window-manager hints or do it new-style with such hints and possibly waiting for a FocusIn event? >> Note that `x-focus-frame' uses XSetInputFocus together with >> x_ewmh_activate_frame. This mixture seems slightly frightening. > > Yes, this looks like "programming by accident". ... rather "better safe than sorry". >> Does it do so even with `focus-follows-mouse' nil? > > select-frame-set-input-focus seems to work identical for > focus-follows-mouse and click-to-focus mode. The frame receives the > input focus, is raised, and the mouse pointer is moved to its upper > right corner. Ahhh no, this time I meant the Emacs option `focus-follows-mouse'. `select-frame-set-input-focus' moves the mouse iff that is non-nil. >> (defcustom pop-up-frame-activate nil >> "When non-nil try to explicitly activate popped up frames. >> If this is nil leave it to Emacs how to activate the frame. If >> this is t always try to activate a new frame. Anything else >> means activate a frame if and only if it existed before the most >> recent call to `display-buffer' ..." >> :type '(choice (const :tag "System Dependent" nil) >> (const :tag "Existing frames only" 'existing-only) >> (const :tag "Always" t)) >> :group 'frames) > > I'm not sure that this issue must be customizable at all. As a user of > pop-to-buffer, I don't quite see the usefulness of the "System > Dependent" and "Existing frames only" choices. An Emacs implementor > could argue that "System Dependent" is simpler to implement, but if the > more complicated variants are implemented too it's no longer "simpler". The "System Dependent" choice is necessary to let the current (maybe faulty for some or many of us) behavior carry over for those who like it as it is. The question is whether we want to distinguish the other two. > I propose this change instead: [...] > (let ((old-frame (selected-frame))) > (select-window (display-buffer buffer other-window) norecord) > (unless (eq old-frame (selected-frame)) > ;; select-window doesn't set the input focus. Set it explicitly. > ;; FIXME: select-window should request focus (perhaps lazily). > (select-frame-set-input-focus (select-frame)))) > buffer)) I suppose you mean (select-frame-set-input-focus (selected-frame)))) here. This has the drawback that we unconditionally do `select-frame-set-input-focus' for new frames. If we decide that this won't harm ... My experience is that once in a while some window manager won't get along with whatever we decide here. Hence I'd like to put in one or two options so users can try an alternative without immediately affecting the behavior of this on other systems. martin