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 13:29: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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1475325039 31414 195.159.176.226 (1 Oct 2016 12:30:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Oct 2016 12:30:39 +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 14:30:29 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 1bqJQn-0005Uz-BB for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Oct 2016 14:30:17 +0200 Original-Received: from localhost ([::1]:55691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqJQl-000072-Vq for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Oct 2016 08:30:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqJQc-0008VA-H9 for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 08:30:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqJQY-00038Y-Cb for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 08:30:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqJQY-00038N-8y for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 08:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bqJQY-0001FX-3k for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 08:30: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 12:30: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.14753249784756 (code B ref 24500); Sat, 01 Oct 2016 12:30:01 +0000 Original-Received: (at 24500) by debbugs.gnu.org; 1 Oct 2016 12:29:38 +0000 Original-Received: from localhost ([127.0.0.1]:40379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqJQA-0001Ed-7J for submit@debbugs.gnu.org; Sat, 01 Oct 2016 08:29:38 -0400 Original-Received: from mail-vk0-f52.google.com ([209.85.213.52]:33343) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqJQ8-0001EQ-8S for 24500@debbugs.gnu.org; Sat, 01 Oct 2016 08:29:36 -0400 Original-Received: by mail-vk0-f52.google.com with SMTP id z126so125922462vkd.0 for <24500@debbugs.gnu.org>; Sat, 01 Oct 2016 05:29: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=4u1X5c5JB1jzMlofjPWJzAF1kx3Rdc35UMJiUBtkJFQ=; b=OkL7OO2SFcuQ6mFoLUagWGM7HXg/Wy5pp9hIYZsC9yNQp035jSdDMvMPjhHpni9QP+ gUYrP0H7RJAiuz0g/fgklVDsPvrCrh9cq6HhnjFomX38V4jjOQaHtv6nlbaCPjs1u+v2 2mjEH/ixwatqndbfRIT0TMunZFB1rK1cKVwkWtV7G8nybERcLKlUPcqgaMXEu0oNTv4v a7TEXMPOitAtJmUGQXQdz0nmBQXwR6A0xPY6ouLL0I6+cH48sWXhQyaLbW1zBL+XJxLc 5qYIXEtKagjAI5coZ5DlD3+CkA1UiwphKMDRBLrDoJXZ2tXiiqaoFb1QcO9Wni7mmOhW zN+A== 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=4u1X5c5JB1jzMlofjPWJzAF1kx3Rdc35UMJiUBtkJFQ=; b=RMsp4RVCIP2awADEI1TWF8Z+9sj+K8iFxGk1hqsbTIxMWXoSRXALL4P3LFo5vVJqKP DhYyMuAVEqrGcZEgMrpXzzmgAeLcahVJ5wEr8H9xK2oFUa6yphOdiAyfPKpSawBQ+Afb mjMANVgbF2Rjmb+T83wYmzATW9lZz29IjbOZUViqgV2Ag+DxRKAdcce8GQQt9YBmY4qO afeM0GfmCh7h8Agf2nNhOGJYpP5u32lttOD1E9/JuI+iU6fVawdsWqmJK57egT+fk5LG suO9tR7gfFhXaYztJBN+JefiTEaW55SQN+DmcbdTRgYKZEYt8HmiNF45SV4D7s3tU1Pi Bz/Q== X-Gm-Message-State: AA6/9Rnx8mhaKuMTpFo9GW0YGFmoMf/RPKL5pJXKx4NqWr/blGvWAWzSfMFnKCI2lU6moMuuT0y44xx29h0Y1g== X-Received: by 10.31.109.195 with SMTP id i186mr8777948vkc.105.1475324970665; Sat, 01 Oct 2016 05:29:30 -0700 (PDT) Original-Received: by 10.159.40.1 with HTTP; Sat, 1 Oct 2016 05:29:00 -0700 (PDT) In-Reply-To: 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:123841 Archived-At: On 1 October 2016 at 11:30, Richard Copley wrote: > On 1 October 2016 at 09:44, martin rudalics wrote: >>>> Why do you think so? The selected frame is frame 1 ever since C-x o >>>> selected it (and it did so twice in a row). >>> >>> OK, then I now realize I have no idea what "selected frame" means. >> >> Did you read section "28.10 Input Focus" of the Elisp manual: > > Yes. > >> Is there >> anything in your scenario that contradicts what has been written there? > > I don't think so. > >>> The fact I was attempting to express is that the activated window >>> at the window-manager level is frame 2. >> >> 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. > >> Note that there is only one visible difference between C-x 5 o and C-x o >> in your scenario: The window selected after C-x 5 o must be on the other >> frame. > > Here, after typing M-x in *scratch* in the recipe: > * if I type C-x o the activated window does not change; > * if I type C-x 5 o the activated window does change. > > Is that the visible difference you mean? > >> The window selected after C-x o can be on the same or the other >> frame and depends on the cyclic ordering of windows. In either case the >> "The selected window always resides on the selected frame." invariant is >> preserved. > >> There is one Emacs internal difference: While focus is "redirected", the >> window for which this happens still gets the selected window's mode-line >> appearance. As a rule, that behavior is always used during minibuffer >> input, probably because it would be distracting to change highlighting >> after typing M-x. But keep in mind that the window initially selected >> during minibuffer input is the minibuffer window and not that with the >> highlighted mode-line - regardless whether the minibuffer window is on >> the same frame or another one. >> >>> >> I'm not sure I understand what you mean here. Do you mean that C-x 5 o >>> >> after the C-g does not select window2? >>> > >>> > I'd better assume that I don't know what "select window2" means either. >>> > >>> > I mean that the window with the solid flashing cursor where text is >>> > inserted >>> > when you type characters is window2, >>> >>> Not window2, sorry. Rather, it's the window displaying *scratch* on frame >>> 1. >> >> 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. > >>> > and that can't be changed by >>> > typing Alt-Tab >> >> 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. > >>> (which on this Windows system is not passed to Emacs but >>> > activates a different window), >> >> Which one? > > Whichever one you want. > >>> nor by clicking on the non-client area of frame >>> > 1 >> >> But you already are in frame 1. What should that click accomplish? > > Firstly, no, I'm in frame 2. > > 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. > >>> In fact I hadn't tried C-x 5 o. That does fix things. >> >> Anything doing C-x o repeatedly wouldn't fix? > > Yes. > >>>>> but clicking inside a window on frame 2 does remove >>>>> the redirection and get things back to normal. >>> >>>> What was abnormal before? >>> >>> I have no idea what's normal and what isn't any more :) >>> >>> I had expected activating frame 2 (using the window manager) to let me >>> type characters into window2. >> >> 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. > Thanks. There's a screen-capture video here: https://buster.me.uk/emacs-bug24500-patch1.webm Before the video starts I do this: M-x load-file RET x.el RET ;; Creates and selects a minibuffer-less frame. C-x b window2 RET ;; Select named window in frame 2 for clarity. ;; Arrange the initial frame 1 on the left and the minibuffer-less frame 2 on the right. At this point the video begins. ;; Click inside *scratch* in the left frame. M-x ;; Click the title bar of the Right Window. C-x o ;; Select window *scratch* in frame 1. C-x o ;; Select minibuffer. C-g ;; Quit M-x At this point (around 6 seconds in) the flashing solid cursor is in the left window, and as you can see by the title bar, the activated window is the window on the right. (The title bar text is black in the active window, grey in inactive windows.) I gather that in your tests, Martin, the window on the left is active at this point. If so then right here is where things first differ for me. xxx ;; Characters inserted in *scratch* ;; Click on the title bar on the left. xxx ;; Characters inserted in *scratch* ;; Click on the title bar on the right. xxx ;; Characters inserted in *scratch* ;; Click inside window2 on the right. xxx ;; Characters inserted in window2. This is recorded while using Windows 10. The same thing happens on my laptop using Windows 7.