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: Mon, 3 Oct 2016 19:32:31 +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> <57F0058A.40806@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1475519667 12797 195.159.176.226 (3 Oct 2016 18:34:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 3 Oct 2016 18:34:27 +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 Mon Oct 03 20:34:23 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 1br84E-0002ms-D0 for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Oct 2016 20:34:22 +0200 Original-Received: from localhost ([::1]:38621 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1br84C-0007eB-Vm for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Oct 2016 14:34:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1br83x-0007Yf-Go for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2016 14:34:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1br83u-0001IV-7s for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2016 14:34:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1br83u-0001IJ-2r for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2016 14:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1br83t-00016s-Qu for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2016 14:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Oct 2016 18:34:01 +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.14755195884153 (code B ref 24500); Mon, 03 Oct 2016 18:34:01 +0000 Original-Received: (at 24500) by debbugs.gnu.org; 3 Oct 2016 18:33:08 +0000 Original-Received: from localhost ([127.0.0.1]:43290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1br832-00014t-Gg for submit@debbugs.gnu.org; Mon, 03 Oct 2016 14:33:08 -0400 Original-Received: from mail-ua0-f178.google.com ([209.85.217.178]:33629) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1br831-00014U-2w for 24500@debbugs.gnu.org; Mon, 03 Oct 2016 14:33:07 -0400 Original-Received: by mail-ua0-f178.google.com with SMTP id v7so83858510uaa.0 for <24500@debbugs.gnu.org>; Mon, 03 Oct 2016 11:33:07 -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=aRBs40KED83aQ2PWijzBED+icVuS9HkBbsGOfMQ3/QY=; b=hJwc7qFakD32yAqaecqe0lgI6/FXIu7tKnzOk3GBqo8UtQLz3whcQITrSDGy16LgBm a1UnKB02qIyCOmpBPlWjuTkU4QHloVW108cTq9T/UexAL9k0h8tSAOGX9BH+DQdL0D31 CsciNJIN0t6pj7iHBhOC0lapNbrYzg0gsHSpz0jwY+Daw2IbMkN8TKAeHxnlX/FBvW2P lC6SELvwoh0mkWmac6vE2++LFOBKyBPmdDvOm4SQq6OYhVsn9LVuStCpvqU4o+9DMnjh OlgxzbOpqyvkWzCvhurkzmmx86ZgVzhm9ydG4JGbX5yPPAPUYaz3U6BZHXGePaCETk03 qARQ== 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=aRBs40KED83aQ2PWijzBED+icVuS9HkBbsGOfMQ3/QY=; b=R4DXSJhooAx7BXN8OF89deYEirt4cbMOwGyn88vKRgKKuHpxwCWKFvYhyf48Lh1Mno bXIGUaI2IJwoGij4TRvnFiWXFHxaqZgT4VW/bCHKtdmT9d6wmUOPqjmTPMZQ3olHE8UP lXwAVlFsRvA2/1+vHHIe96VVt+OrziWkBRJn8hClIwKefYNDP636krXXY0BeIs7sVKOY EP8uOeysTNHMdInXv+PlcVVP9aKVrEnTOCR7isC6AMskvM+l27vDD1AKbbIOvU3UGJ8f T74PSKvkNGADeA2rHax9Q04ssPV7myH7MtivxOwulB51J7hZcBnXA3SSu1xhI9qopPh2 VfYw== X-Gm-Message-State: AA6/9Rl7weF7JLmhgDdPCewZr3ADGE/tMIh9brfttzRwx87Dn1xot7IS//zJWBxzG0/cusVsa40RYo69maaa4g== X-Received: by 10.159.32.101 with SMTP id 92mr12399925uam.123.1475519581560; Mon, 03 Oct 2016 11:33:01 -0700 (PDT) Original-Received: by 10.159.40.1 with HTTP; Mon, 3 Oct 2016 11:32:31 -0700 (PDT) In-Reply-To: <57F0058A.40806@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:123972 Archived-At: On 1 October 2016 at 19:50, martin rudalics wrote: >>> 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)? > > Hmmm... I could have sworn it did so. But it doesn't. > > So the answer is (until further notice): The frame where I typed M-x > into is the one whose title bar is painted active throughout the > subsequent C-x o sequence. > >> 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. > > It's "No" actually, but maybe I didn't pay enough attention to that > earlier. Anyway: Typed text always applis to the window selected via > C-x o. Can you confirm that? Yes. >>> 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). > > OK. It seems that after all we do see the same behavior with respect to > C-x o and C-x 5 o. Right. And the behaviour towards the end of the video, where clicking on the title bars doesn't affect the window where typed characters are inserted: do you see the same thing there 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. > > But then the "title bar activation doesn't follow the input focus" > behavior is just the same, regardless of whether you issue the M-x in > the minibuffer-equipped or in the minibuffer-less frame. Can we agree > that the frame where we issue the M-x keeps the title bar activated for > the entire C-x o sequence until we either type C-x 5 o or C-g in the > minibuffer? Yes. >>> 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. > > I'd still want to see comments from other Windows users on this. Can > you provide a scenario people can test on an unpatched emacs -Q where > > (make-frame '((minibuffer . nil))) > > followed by M-x in the new frame doesn't allow switching frames via > Alt-Tab or mouse clicks as long as the minibuffer is active? We need a > third opinion on this. No, I haven't noticed such a scenario. >> Just a thought: do you use focus-follows-mouse? I don't. > > You mean the Emacs option? Normally I do use it but not with emacs -Q. > I configured Windows with XMouse support such that hovering the mouse > over a window will give it focus and raise it - but this can hardly be > more powerful than clicking into a window. > > [In fact, as I just noticed, it isn't. During focus redirection, I can > confuse Windows by typing C-x o with the consequence that now the frame > I move the cursor to gets the active titlebar but blinking cursor and > input focus remain on the frame where the mouse movement started. Only > as soon as I mouse-click into a frame, moving the cursor to the other > frame makes the behavior congruent again - that is blinking cursor and > input focus again move with the active titlebar.] > > And Alt-Tabbing should not be affected by this setting anyway. Well, > Redmond occasionally had troubles with the Alt-Tab code ... OK. I was wondering if some setting or third-party tool could explain the differences between what you and I were seeing, but if there is no difference after all (?) then it's not worth thinking about. > martin