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: Sat, 23 Aug 2008 14:05:58 +0200 Message-ID: <48AFFD26.3040204@gmx.at> References: <48AC2F4A.1000507@gmx.at> <48AC851A.3020906@gmx.at> <48AD2FB5.3000204@gmx.at> <48ADD085.50505@gmx.at> <48AEEBB8.50201@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-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1219494462 14315 80.91.229.12 (23 Aug 2008 12:27:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Aug 2008 12:27:42 +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 Sat Aug 23 14:28:35 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 1KWsEM-00083M-Ty for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Aug 2008 14:28:35 +0200 Original-Received: from localhost ([127.0.0.1]:39170 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KWsDO-0000Pn-T1 for geb-bug-gnu-emacs@m.gmane.org; Sat, 23 Aug 2008 08:27:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KWsDL-0000PJ-8d for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2008 08:27:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KWsDK-0000P1-Ui for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2008 08:27:30 -0400 Original-Received: from [199.232.76.173] (port=47563 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KWsDK-0000Ox-Hh for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2008 08:27:30 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:49041) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KWsDK-0007uD-CV for bug-gnu-emacs@gnu.org; Sat, 23 Aug 2008 08:27:30 -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 m7NCRRLf029722; Sat, 23 Aug 2008 05:27:28 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m7NCK50G026969; Sat, 23 Aug 2008 05:20:05 -0700 X-Loop: don@donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 23 Aug 2008 12:20: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.121949341124137 (code B ref 745); Sat, 23 Aug 2008 12:20:04 +0000 Original-Received: (at 745) by emacsbugs.donarmstrong.com; 23 Aug 2008 12:10:11 +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 m7NCA4LS023705 for <745@emacsbugs.donarmstrong.com>; Sat, 23 Aug 2008 05:10:05 -0700 Original-Received: (qmail invoked by alias); 23 Aug 2008 12:09:58 -0000 Original-Received: from 62-47-44-146.adsl.highway.telekom.at (EHLO [62.47.44.146]) [62.47.44.146] by mail.gmx.net (mp062) with SMTP; 23 Aug 2008 14:09:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/IQuNVbfXIWsAwfo0+v654h/7magDbA3rFQ80O6r kSK3L3c7CuLB7j User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Sat, 23 Aug 2008 08:27:30 -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:19661 Archived-At: > 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. Rather "which (wrongly) has the input focus for window managers able to handle mapping a new frame without giving input focus to it" because IIUC with certain settings (focus-follows-mouse) some window managers automatically do give focus to the new frame. I also suppose that the only means to take focus away from the new frame is by giving focus to the previously selected frame (though we can't even be sure that frame had focus or was risen). > (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.) I think so. But what happens in the `pop-to-buffer' case when a _new_ frame gets displayed. Should we give it input-focus? I suppose so from your situation B comments below. So in all cases where situation A has Y (that is `display-buffer' fails TDTRT) `pop-to-buffer' DTRT? > 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.) Do we agree on the general rule that - `display-buffer' should never try to move input focus to another (new or existing) frame, while - `pop-to-buffer' should try to give input focus to the frame where BUFFER is displayed (this could be the selected frame as well). > Let's call the display-buffer case, situation A and the pop-to-buffer > case, situation B. [...] > 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) I'm completely ignorant WRT to focus-window-when-mapped: Does this mean that a window that is not risen can get focus? Note in this context that `select-frame-set-input-focus' always raises the frame. > ? N Metacity follow-mouse (mouse) > ? N Metacity follow-mouse (sloppy) > ? N Metacity click-to-focus (click) Does Metacity respect `select-frame-set-input-focus' at all? > 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) For the M cases `raise-frame' could move the mouse pointer to that frame which seems to call for yet another option. > Y N FluxBox click-to-focus > Y Y IceWM click-to-focus So IceWM is the only window manager to handle situation B. IIUC it does so because do_switch-frame manages to get Fredirect_frame_focus through to redirect input to that frame. Or do you have another explanation? Could you try to GDB do_switch_frame for IceWM and one of the others to see they do differently? > 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. Can we conclucde that the other window managers implicitly focus a frame when mapping it? > The docstring for select-window could perhaps > also state a bit more prominently that the "selected window" and the > "input focus" are different things ... if the implementation is bogus this will hardly help ... > or at least refer to > select-frame-set-input-focus. That function lumps together too many things. At least `raise-frame' should probably be optional there. > BTW, below is a proof of concept implementation for the > update-focus-lazily idea. Would this work with `redirect-frame-focus'? I haven't studied it in detail. martin