From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.bugs Subject: bug#745: pop-to-buffer, frames, and input focus Date: Thu, 28 Aug 2008 18:47:28 +0200 Message-ID: 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> <48B69007.20604@gmx.at> Reply-To: Helmut Eller , 745@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1219943323 702 80.91.229.12 (28 Aug 2008 17:08:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Aug 2008 17:08:43 +0000 (UTC) Cc: 745@emacsbugs.donarmstrong.com To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 28 19:09:37 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 1KYkz6-0002HQ-LD for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Aug 2008 19:08:36 +0200 Original-Received: from localhost ([127.0.0.1]:45458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYky7-0004U2-QP for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Aug 2008 13:07:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KYky4-0004Tl-K9 for bug-gnu-emacs@gnu.org; Thu, 28 Aug 2008 13:07:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KYky4-0004TV-1k for bug-gnu-emacs@gnu.org; Thu, 28 Aug 2008 13:07:32 -0400 Original-Received: from [199.232.76.173] (port=55852 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYky3-0004TS-Ud for bug-gnu-emacs@gnu.org; Thu, 28 Aug 2008 13:07:31 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:33120) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KYky3-0002Qb-DE for bug-gnu-emacs@gnu.org; Thu, 28 Aug 2008 13: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 m7SH7TSf002443; Thu, 28 Aug 2008 10:07:29 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m7SGt5kr029710; Thu, 28 Aug 2008 09:55:05 -0700 X-Loop: don@donarmstrong.com Resent-From: Helmut Eller Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Thu, 28 Aug 2008 16: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.121994196227684 (code B ref 745); Thu, 28 Aug 2008 16:55:04 +0000 Original-Received: (at 745) by emacsbugs.donarmstrong.com; 28 Aug 2008 16:46:02 +0000 Original-Received: from rolmail.net (cgp1.rolmail.net [195.254.252.190]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m7SGjsAp027590 for <745@emacsbugs.donarmstrong.com>; Thu, 28 Aug 2008 09:45:55 -0700 Original-Received: from dummy.name; Thu, 28 Aug 2008 18:45:51 +0200 Original-Received: from dummy.name; Thu, 28 Aug 2008 18:47:29 +0200 In-Reply-To: <48B69007.20604@gmx.at> (martin rudalics's message of "Thu, 28 Aug 2008 13:46:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Thu, 28 Aug 2008 13: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:19807 Archived-At: * martin rudalics [2008-08-28 13:46+0200] writes: >> 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? This takes more than a few hours of hacking. At least a few days, more likely a few weeks. That's to much time for such a minor nicety. Improving select-window so that it request input focus (somewhat efficiently) would be more worthwhile. >> 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? No. select-frame-set-input-focus seems to be the only focus related function (despite x-focus-frame which is presumably internal). If we interpret select-frame-set-input-focus as "request input focus" and not as "request input focus and wait until we know that we actually have the focus" then we don't need to wait. IMO, the former interpretation is consistent with the usual assumption that Emacs updates the display "later" or at least not in lock step with Lisp code. >> 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 know about the following problems: 1. pop-to-buffer doesn't switch input focus 2. select-window doesn't switch input focus 3. x-create-frame does switch input focus (with most WMs) Is there something else? We agreed that we wont fix 3. 1 would be fixed by calling select-frame-set-input-focus in pop-to-buffer (either customizable or not). Do we need to test something? Fixing 2 isn't so clear. This was shortly discussed on the mailing list but RMS said, at that time, that more important things should be done. >> 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. It would be reasonable to minimize the number of people who need to change the defaults. >> 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. Some people, like me, who do actually care, also like to keep the code readable, simple, and predictable. New customization options cost a lot in terms of readability. Helmut.