From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present Date: Sat, 1 Oct 2016 15:54:00 +0100 Message-ID: References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57EE232E.4090301@gmx.at> <57EF7776.80703@gmx.at> <57EFB568.7070305@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1475333725 8290 195.159.176.226 (1 Oct 2016 14:55:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Oct 2016 14:55:25 +0000 (UTC) Cc: 24500@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 01 16:55:20 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqLh5-00014d-Uz for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Oct 2016 16:55:16 +0200 Original-Received: from localhost ([::1]:56075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqLh4-0006Em-F1 for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Oct 2016 10:55:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55431) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqLgx-0006C6-Lm for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 10:55:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqLgs-0000pV-MQ for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 10:55:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqLgs-0000pM-IP for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 10:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bqLgs-0004rP-2f for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 10:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Oct 2016 14:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24500 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24500-submit@debbugs.gnu.org id=B24500.147533367818647 (code B ref 24500); Sat, 01 Oct 2016 14:55:02 +0000 Original-Received: (at 24500) by debbugs.gnu.org; 1 Oct 2016 14:54:38 +0000 Original-Received: from localhost ([127.0.0.1]:41235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqLgT-0004qg-VX for submit@debbugs.gnu.org; Sat, 01 Oct 2016 10:54:38 -0400 Original-Received: from mail-ua0-f176.google.com ([209.85.217.176]:36112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqLgS-0004qV-Qh for 24500@debbugs.gnu.org; Sat, 01 Oct 2016 10:54:37 -0400 Original-Received: by mail-ua0-f176.google.com with SMTP id n13so117691340uaa.3 for <24500@debbugs.gnu.org>; Sat, 01 Oct 2016 07:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tFnJGWbkdYdtJH0qvMOcDrT6NN69VBBuXqefo8iUo0o=; b=zgFa+Ckua8ucmtvl/y8ptEwsT6Sna6sJRXB3tixNga1xiwO+TZQ/i/C2RoGLIi5in6 z2rJsccdRvqP4EjqySyf0shbFgRew36A7+4Sf01x7Q5oVm6Csd0CAKFz19PIKuwaepUe 6L15inMZTFpoJX42laJxR9TCSgPM9ly39oWn3yuRIK7h8ptLaxn8kcus3J9oHmCeBQYV cFQRuIbeprDuWpGCazHNK3dkgw+uq8Zk6Pk34DvDpa+iJqt8isPkWIeANc/nYV/4SuJm rM8llq+m9Obje80eDcCcVyvHpPf+/VUySdwgtxWJuW/r6jFT3tFLqooFYSUPvbT2ShGQ r/PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tFnJGWbkdYdtJH0qvMOcDrT6NN69VBBuXqefo8iUo0o=; b=k4pmy2p7K3mbbQ8Amz9zKz/9MLEkwVsmbrIG/ahI+LYsMcCzR/xCwF/jZUJml9DCek DhHuFV6DxDwnUfU2DI3STbRUHdL3mGT27RXsjgzm5PNpnUTp9JGPOYJtFtlTEWHP2be2 wxR1DMPuHrVAz5tRG7wDNHnTjG6h652XIZNMni60snH9U5fAlosBPvSpPa7suOusyaJC Jo9k+Rhf3N5OgVpmw6KqBiS7Q1GrFEPhRjh9IW/QG0LmeDfaV9xBOVcnbkINZmy6wFyT REuu4lHsiIN21ZES6lKfGfdMyMjQuIvcsMdUohyIswTF1negm4BpuK1FsS8+6916arH5 rfew== X-Gm-Message-State: AA6/9Rk/FGyxE+IilO8urQT4Rlu0JG21DYiMotqUMY51TEOAKvsWbVmZJlJdTCK7cfA9rZmcXuSVh1rYjIxCQA== X-Received: by 10.176.5.164 with SMTP id e33mr295786uae.91.1475333671310; Sat, 01 Oct 2016 07:54:31 -0700 (PDT) Original-Received: by 10.159.40.1 with HTTP; Sat, 1 Oct 2016 07:54:00 -0700 (PDT) In-Reply-To: <57EFB568.7070305@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:123850 Archived-At: On 1 October 2016 at 14:08, martin rudalics wrote: >>> With "activated window at the window-manager level" you mean the window >>> that has input focus and has its title bar painted differently from >>> other windows but is not necessarily the topmost window in the Z-order? >>> That window is here the one showing frame 1 after you switched to it via >>> C-x o. >> >> It's the one showing frame 2, as I said. > > So we seem to have another problem. Just to make sure, I use a mingw32 > build of Emacs 25 on Windos XP with the following patch > > --- a/src/frame.c > +++ b/src/frame.c > @@ -1157,7 +1157,10 @@ do_switch_frame (Lisp_Object frame, int track, int > for_deletion, Lisp_Object nor > if (FRAMEP (xfocus)) > { > focus = FRAME_FOCUS_FRAME (XFRAME (xfocus)); > - if (FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ()) > + if ((FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ()) > + || (NILP (focus) > + && EQ (FRAME_MINIBUF_WINDOW (XFRAME (frame)), > + sf->selected_window))) > Fredirect_frame_focus (xfocus, frame); > } > } Ah. I'm on the master branch (using a mingw64 build on Windows 10, with the same patch). emacs-repository-version is e1c5422e7bc2fbe0ecf5ab501b39d32fac61e747. (Time passes ...) I do see exactly the same on the emacs-25 branch as I see on the master branch. emacs-repository-version is f1247f069e6a908595748c315948c636962b60dc. > Now with emacs -Q I put the following form > > (make-frame '((minibuffer . nil))) > > in *scratch* and evaluate it via C-x C-e. This gets me a new frame, say > F2 which is selected and has input focus. To avoid confusion I make the > sole window in F2 show *Messages*. > > Now I do C-x 5 o which gets me back to the initial frame, say F1. F1 is > selected and has input focus. Now I do M-x. F1 is still selected and > has input focus. Now I do C-x 5 o. F2 gets selected and has input > focus. Can we agree until here? Yes, agreed. And what's more, until here the window manager's window activation (as evidenced by the text style in the title bar) has followed the selected frame. > Now I do C-x o. This selects F1 and gives it input focus with the > *scratch* window selected. Typed text appears in *scratch*. If F1 and > F2 overlap, F2 obscures F1. I suppose you observe something different > here. In this terminology, does "selects F1 and gives it input focus" imply that the F1 becomes the active window (in other words, that its title bar is painted active)? If "Yes" then yes, I observe something different, that the window does not get activated (i.e., its title bar text remains grey). If "No" then no, I observe all of that, and I also observe that the window does not get activated. > Now I do C-x o again. This selects the minibuffer window on F1. > Typed text now appears in the echo area. Agreed. >> Here, after typing M-x in *scratch* in the recipe: >> * if I type C-x o the activated window does not change; > > You mean C-x o does not take you to F2 in my parlance. Here F2 gets > selected and input focus. I'm not sure what you mean. In my case F2 becomes the selected frame in the sense of (selected-frame), and typed text goes to the selected window of frame F2 (it goes to *scratch*), and F1 remains the active window (the one with black title bar text). >> * if I type C-x 5 o the activated window does change. >> >> Is that the visible difference you mean? > > It's not in your original scenario but apparently our installations > differ here. Are you sure you applied the same change as I did? I applied the same change as you did. >>> But what's wrong with that? After all you _did_ use C-x o to select >>> that window. >> >> It's not wrong until you type Alt-Tab. > > Alt-tabbing was not part of your scenarios so far. Please give a > step-by-step recipe indicating the first time it fails. OK, but as a matter of fact, I was talking about Alt-Tab in the original recipe in message #23, and I clarified that in message #29. Sorry if I haven't been making myself clear. I think the video has helped. >>> Do you mean that on frame 1 you cannot use Alt-Tab to switch to frame 2? >> >> Possibly. >> >> Typing Alt-Tab several times switches the window-manager's activation >> between frame 1 and frame 2 (and other windows that may be present >> if you hold Alt and type Tab more than once). I can switch activation >> between >> the two Emacs windows and any other windows as much as I like, as >> evidenced by the title-bar painting style. >> >> But no amount of typing Alt-Tab changes which Emacs window contains >> the solid flashing cursor where text is inserted when I type characters. > > Here Alt-Tab always switches between all Emacs frames. Otherwise we > would have had problems on any multi-frame layed-out Emacs. And > certainly we would have had problems in an unpatched Emacs when invoking > M-x from the minibuffer-less frame. Can you try if C-x o fails for that > as well? In an unpatched emacs (on master, the emacs from my original report, emacs-repository-version 7fa96cb5ef8c8464496688e88c1b97211a820d79), C-x o doesn't fail. It can cycle through all three windows more than once. The title bar activation doesn't follow the input focus; the minibuffer-less frame's title bar remains activated throughout the M-x C-x o C-x o ... sequence (I'm not saying that's wrong, I'm just saying that's what happens). Doing C-g in the minibuffer correctly returns the input focus to the minibuffer-less frame. >> Firstly, no, I'm in frame 2. > > So you mean that frame 2 has input focus and is selected and clicking on > frame 1 does not select frame 1 and give it input focus? Something must > be broken on your side. Yes, apparently. >> Secondly, I'm saying that any amount of switching between windows, >> either using Alt-Tab, or by clicking on title bars, makes no difference >> to the window where text is inserted. > > Can anyone observe that? I just tried on Windows 7 and see the same > behavior as on XP. > >>> Here at any moment I can use Alt-Tab or the mouse to select any of the >>> three windows involved in your scenario and continue typing text there. >>> If this doesn't work on your system please tell me precisely where it >>> fails. >> >> I have tried to do that. > > I'm left without clues. Just a thought: do you use focus-follows-mouse? I don't. > martin