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: Thu, 28 Aug 2008 13:46:15 +0200 Message-ID: <48B69007.20604@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> <48B50C63.8010402@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 1219925287 30564 80.91.229.12 (28 Aug 2008 12:08:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Aug 2008 12:08:07 +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 Thu Aug 28 14:08:58 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 1KYgIm-0000rS-8L for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Aug 2008 14:08:36 +0200 Original-Received: from localhost ([127.0.0.1]:50674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYgHn-0006R0-G8 for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Aug 2008 08:07:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KYgHk-0006Qv-UL for bug-gnu-emacs@gnu.org; Thu, 28 Aug 2008 08:07:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KYgHk-0006QU-H9 for bug-gnu-emacs@gnu.org; Thu, 28 Aug 2008 08:07:32 -0400 Original-Received: from [199.232.76.173] (port=44377 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYgHk-0006QR-34 for bug-gnu-emacs@gnu.org; Thu, 28 Aug 2008 08:07:32 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:45994) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KYgHj-0003Kb-40 for bug-gnu-emacs@gnu.org; Thu, 28 Aug 2008 08:07: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 m7SC7TZq032352; Thu, 28 Aug 2008 05:07:29 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m7SBt4Qv027221; Thu, 28 Aug 2008 04:55:04 -0700 X-Loop: don@donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 28 Aug 2008 11:55:04 +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.121992419125488 (code B ref 745); Thu, 28 Aug 2008 11:55:04 +0000 Original-Received: (at 745) by emacsbugs.donarmstrong.com; 28 Aug 2008 11:49:51 +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 m7SBnk8H025395 for <745@emacsbugs.donarmstrong.com>; Thu, 28 Aug 2008 04:49:48 -0700 Original-Received: (qmail invoked by alias); 28 Aug 2008 11:49:40 -0000 Original-Received: from 62-47-37-235.adsl.highway.telekom.at (EHLO [62.47.37.235]) [62.47.37.235] by mail.gmx.net (mp040) with SMTP; 28 Aug 2008 13:49:40 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/4FUBdwz342ZiTO6UkM70JsYyc/At0E6+amOJNhf wfSjUrQrOoytqN User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Thu, 28 Aug 2008 08:07:32 -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:19792 Archived-At: > A way to call one of XSetInputFocus or x_ewmh_activate_frame without > calling the other would be useful for experimentation. But I think that > few people will use/need that. So, no, it shouldn't be customizable. I'm afraid that we fix this just for the platforms we use. If someone reports a breakage of this on another platform before the release we might be able to fix it there as well. Otherwise this will go the way of most "fixes" in this department. > It think it would be nice (but not worth to implement) if Emacs could be > customized with two "focus models": > > 1. Let the window manager do all the focus handling. This is similar > to what Emacs does currently. In this model Emacs should use > x_ewmh_activate_frame without XSetInputFocus [I think that this would > avoid some race conditions]. pop-to-buffer could > still "activate" the frame, but it would be merely a hint and no > guarantee. Creating frames which aren't focused initially is > probably hard(er) in this model. We agreed that the latter isn't realistic anyway. > 2. Emacs does its own focus management. In this model, Emacs should > clear the input flag in WM_HINTS, handle WM_TAKE_FOCUS events, and > explicitly call XSetInputFocus. A reasonable window manager will > handle FocusIn events to decorate the focused frame appropriately. > Since the input flag is cleared, the WM shouldn't focus new frames. > [This model may be incompatible with toolkits, like GTK.] And why do you think this not worth implementing? > Yes, without waiting. If we call > > (select-frame-set-input-focus (window-frame (display-buffer ...))) > > we don't wait for FocusIn. Is there a place where Emacs _should_ wait for a FocusIn? > Since we don't have a window manager which causes trouble, we can't even > test whether the change makes any difference. Let's wait until somebody > reports actual problems :-) You've read some of the earlier threads - and there's a lot more of these (some of them related to frame resizing). We do have to anticipate such problems now: People usually don't go through the troubles testing this with any window-manager but their own. > I think that, if "System Dependent" stays the default, then few people > will profit from the other choices, simply because few people take the > time to customize it. But if they complain we can give them an option to test. > Despite that, I think that very few people prefer > the current behavior. It's not a question of preference. It might simply work for them. So let's not cause unwanted breakage. >> This has the drawback that we unconditionally do >> `select-frame-set-input-focus' for new frames. If we decide that this >> won't harm ... > > Most of the time it will work flawlessly on new frames. What's the > worst that could happen? Some flickering. I think that we can live > with that imperfection. Maybe there's more than just some imperfection. martin