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: Sat, 23 Aug 2008 10:55:04 +0200 Message-ID: References: <48AC2F4A.1000507@gmx.at> <48AC851A.3020906@gmx.at> <48AD2FB5.3000204@gmx.at> <48ADD085.50505@gmx.at> <48AEEBB8.50201@gmx.at> Reply-To: Helmut Eller , 745@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1219482641 17317 80.91.229.12 (23 Aug 2008 09:10:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Aug 2008 09:10:41 +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 Sat Aug 23 11:11:33 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 1KWp9X-0006lQ-Ax for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Aug 2008 11:11:23 +0200 Original-Received: from localhost ([127.0.0.1]:39185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KWp8X-0001Hl-Ot for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Aug 2008 05:10:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KWp5u-0000k0-Sr for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2008 05:07:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KWp5p-0000gU-No for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2008 05:07:37 -0400 Original-Received: from [199.232.76.173] (port=52137 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KWp5o-0000fz-1W for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2008 05:07:32 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:52575) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KWp5m-0006wm-Ce for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2008 05: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 m7N97RcC030511; Sat, 23 Aug 2008 02:07:28 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m7N903Q0026823; Sat, 23 Aug 2008 02:00:03 -0700 X-Loop: don@donarmstrong.com Resent-From: Helmut Eller Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 23 Aug 2008 09:00:03 +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.121948162725121 (code B ref 745); Sat, 23 Aug 2008 09:00:03 +0000 Original-Received: (at 745) by emacsbugs.donarmstrong.com; 23 Aug 2008 08:53:47 +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 m7N8rf1r025115 for <745@emacsbugs.donarmstrong.com>; Sat, 23 Aug 2008 01:53:43 -0700 Original-Received: from dummy.name; Sat, 23 Aug 2008 10:53:37 +0200 Original-Received: from dummy.name; Sat, 23 Aug 2008 10:55:04 +0200 In-Reply-To: <48AEEBB8.50201@gmx.at> (martin rudalics's message of "Fri, 22 Aug 2008 18:39:20 +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: Sat, 23 Aug 2008 05:07:36 -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:19659 Archived-At: --=-=-= * martin rudalics [2008-08-22 18:39+0200] writes: >>>> pop-to-buffer doesn't switch input focus with: Sawfish, kwin, >>>> metacity, fluxbox, twm. >>>> It does with icewm. >>>> >>>> display-buffer seems to switch focus with: Sawfish, kwin, fluxbox, >>>> icewm, twm. >>> You probably mean display-buffer does _not_ switch focus with these. >> >> I meant to say: display-buffer _does_ switch focus when creating a new >> frame with those window managers: Sawfish, kwin, fluxbox, icewm, twm. > > I still don't understand. Simplistically spoken, `pop-to-buffer' is > `display-buffer' + `select-window'. How can, using Sawfish say, > `display-buffer' switch focus and `pop-to-buffer' not switch focus? Sorry, that was indeed confusing. The problematic cases are (let ((pop-up-frames t)) (display-buffer ...)) for display-buffer, if the buffer was not visible before. In this case a new frame appears, which (wrongly) has the input focus. (If the buffer is already visible in some frame, that frame is raised but the focus is not moved to that frame. This is IMO correct.) For pop-to-buffer: (let ((display-buffer-reuse-frames t)) (pop-to-buffer ...)) if the buffer is already visible in a frame which has not the input focus. This should move input focus to that frame, but it currently doesn't. (If the frame has already the focus, pop-to-buffer works as it should.) Let's call the display-buffer case, situation A and the pop-to-buffer case, situation B. > > We should fix it this time. Please try again two things with the > window-managers you listed above and `pop-up-frames' non-nil: > > - tell whether `display-buffer' does switch focus. > > - tell whether `pop-to-buffer' does switch focus. > > - try both, if possible, with click-to-focus and a focus-follows-mouse > settings (maybe you have to set the value of the Emacs variable > `focus-follows-mouse' appropriately). OK, here is what I see: A B WM WM focus mode --------------------------------------- Y N Sawfish follow-mouse (enter-only + focus-window-when-mapped) N N Sawfish follow-mouse (enter-only + !focus-window-when-mapped) Y N Sawfish follow-mouse (enter-exit + focus-window-when-mapped) N N Sawfish follow-mouse (enter-exit + !focus-window-when-mapped) Y N Sawfish click-to-focus (click + focus-window-when-mapped) N N Sawfish click-to-focus (click + !focus-window-when-mapped) Y N Sawfish click-to-focus (click + focus-window-when-mapped + focus-click-through) N N Sawfish click-to-focus (click + !focus-window-when-mapped + focus-click-through) ? N Metacity follow-mouse (mouse) ? N Metacity follow-mouse (sloppy) ? N Metacity click-to-focus (click) Y N KWin follow-mouse Y N KWin click-to-focus Y M FluxBox follow-mouse (Sloppy Focus) Y M FluxBox follow-mouse (Auto Raise) Y N FluxBox click-to-focus Y Y IceWM click-to-focus Y N Twm follow-mouse (new frames need mouse click for placement) A and B are the scenarios described above. Y means: Yes, does switch focus. N means: No, doesn't switch focus. ? means: sometimes (probably depending on mouse and window positions) M means: No, doesn't switch focus, except when raising the frame also moves the mouse pointer into the frame. I set Emacs' focus-follows-mouse according to the WM focus mode (except when I forgot it :-) The Ys for Sawfish are apparently directly related to the focus-window-when-mapped option. So, it's probably not Emacs that switches the focus in the A scenario, but the window managers. > > Here on Windos XP with a focus-follows-mouse policy, `display-buffer' > and `pop-to-buffer' both switch focus. IIRC, people reported troubles > with the standard click-to-focus policy. Honestly, I'm a bit reluctant > to try out click-to-focus here, maybe someone else can try? > >> Maybe we could move the input focus to the selected frame in a lazy >> fashion. E.g. when Emacs waits for new events, we could compare the >> currently focused frame with the selected frame, and if they differ we >> could switch the focus to the selected frame. This would make >> select-frame more useful. > > I suppose we should introduce a customizable variable which allows to > call `select-frame-set-input-focus' (or something similar) at least in > `pop-to-buffer' but maybe also in `display-buffer'. But we should also > provide a doc-string recommending what setting this variable should have > on which platform. Yes, that would be good. The docstring for select-window could perhaps also state a bit more prominently that the "selected window" and the "input focus" are different things or at least refer to select-frame-set-input-focus. BTW, below is a proof of concept implementation for the update-focus-lazily idea. Helmut. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=lazy-focus.diff --- keyboard.c.~1.969.~ 2008-08-15 14:47:16.000000000 +0200 +++ keyboard.c 2008-08-23 10:23:12.000000000 +0200 @@ -1602,6 +1602,21 @@ (at your option) any later version. && !EQ (internal_last_event_frame, selected_frame)) Fselect_frame (internal_last_event_frame); #endif +#if 1 + { + if (!detect_input_pending() + && NILP(internal_last_event_frame)) { + Display *dpy = FRAME_X_DISPLAY (check_x_frame(selected_frame)); + Window focus; + int revert_to; + XGetInputFocus (dpy, &focus, &revert_to); + if (focus != None + && focus != FRAME_X_WINDOW (check_x_frame(selected_frame))) + Fx_focus_frame (selected_frame); + } + } +#endif + /* If it has changed current-menubar from previous value, really recompute the menubar from the value. */ if (! NILP (Vlucid_menu_bar_dirty_flag) --=-=-=--