From unknown Thu Jun 19 14:05:39 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#24500 <24500@debbugs.gnu.org> To: bug#24500 <24500@debbugs.gnu.org> Subject: Status: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present Reply-To: bug#24500 <24500@debbugs.gnu.org> Date: Thu, 19 Jun 2025 21:05:39 +0000 retitle 24500 25.1.50; Can't other-window from minibuffer if Ediff control = panel frame present reassign 24500 emacs submitter 24500 Richard Copley severity 24500 minor thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 21 13:24:06 2016 Received: (at submit) by debbugs.gnu.org; 21 Sep 2016 17:24:06 +0000 Received: from localhost ([127.0.0.1]:59818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bmlFe-00072p-EJ for submit@debbugs.gnu.org; Wed, 21 Sep 2016 13:24:06 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55420) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bmlFc-00072M-Jm for submit@debbugs.gnu.org; Wed, 21 Sep 2016 13:24:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmlFT-0003Q1-6Y for submit@debbugs.gnu.org; Wed, 21 Sep 2016 13:23:59 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:46939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmlFT-0003Px-32 for submit@debbugs.gnu.org; Wed, 21 Sep 2016 13:23:55 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmlFR-0006lT-KA for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2016 13:23:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmlFP-0003OZ-9W for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2016 13:23:52 -0400 Received: from mail-yb0-x22d.google.com ([2607:f8b0:4002:c09::22d]:35037) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmlFP-0003OM-4V for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2016 13:23:51 -0400 Received: by mail-yb0-x22d.google.com with SMTP id d69so37408951ybf.2 for ; Wed, 21 Sep 2016 10:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=GQs+UQ9FDi9EY137aSD1mTBoz24EsB9Uqk41wn11M/E=; b=s2InOtOVLj/DgadgDuD0jk5NugllSLqByDF/b2XC2y6uZ6Nyj2mlu3enynSbAtXW6U hxF1nm06DICtuwRcLZwK2e/wHc6oc+reIYJosu8boJqNHWFNl6vgZF62VYsbftB+1oOc 3QsprQa+2aMvmPOWTOoKUIW2wglEevmKSb8wbHd/RHOSH4FJzrlhrK2cN9GGKV+Trmb3 cb5G1ndiHbwdQQHse5UXpzYaryuWeK8IWIqeGU347VykNsLQVJy6NPc+HwtJc2PbMk/8 FT8O9MSKtdG2GyBP8GQSvfY1xpG12e93FlnU9o6QUjnq7JoIVJzVyqHMqSHCsHoUsOib onzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GQs+UQ9FDi9EY137aSD1mTBoz24EsB9Uqk41wn11M/E=; b=lBjSMLCEhzHeFni41+uFEtd6V5TRuT22BKdrbl4KWB/gaB9/cmMRRFH0e3+AAKSmLA hL6LyUcl+cKtH+TZk2BwnfvRfLXsry9CjLpBVoDEWkaeV6TCUm/CJy7d1jzBiHU6lFmH GC31J1ZhiaZHTZ0fuqYq0vZnGvET8CLGb7b27VihFdO7bPim3qXHBPrNatly0Tsb9clF 7LUE4YQbCuU3WAAcSXD2K4YMAt9/ByjXiRlPp4IcDJqfhOVDt2lm9EwalOjhv2+gMLiE 1GVuxjtNGtdqdCZDuKFHT2unpUn0u1Z3UCwHKXN+PdbfYQF7Gb9TRXWe53yMr2f0Vrg7 GKHA== X-Gm-Message-State: AE9vXwOyn7NwW1cZG6CcuGOEI4riUssf3JKxaIt6WmXxf3/1ghmEibKk8dNTAQwGpcbTxRnR1ifmU3eV+RRguQ== X-Received: by 10.37.20.8 with SMTP id 8mr37906553ybu.103.1474478630398; Wed, 21 Sep 2016 10:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.176 with HTTP; Wed, 21 Sep 2016 10:23:20 -0700 (PDT) From: Richard Copley Date: Wed, 21 Sep 2016 18:23:20 +0100 Message-ID: Subject: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: "bug-gnu-emacs@gnu.org" Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) C-x C-o doesn't do anything useful when reading from the minibuffer, if an Ediff control panel frame is present (but not activated). >From 'emacs -Q': ;; To illustrate what C-x C-o is supposed to do: M-x ; select minibuffer C-x C-o ; select *scratch* window while reading from minibuffer ESC ESC ESC ; quit ;; To illustrate what goes wrong when Ediff is active: C-x b * RET ; create a spare buffer so we can invoke ediff-buffers M-x ediff-buffers RET RET RET C-x 5 o ; Activate main frame M-x ; Select minibuffer C-x C-o ; Something not very useful happens At this point in the recipe Emacs is in a strange state. The cursor in the minibuffer is solid but not blinking. There are visual changes in the Ediff control frame as though the window is selected, but the Ediff frame isn't actually activated. Typing C-g doesn't exit the minibuffer (which is still reading the command for M-x). Typing a self-inserting character does send that character to the minibuffer, and returns things to normal. For the "Activate main frame" step of the recipe you can use the Window Manager (mouse click, Alt-Tab, etc.) instead of the Emacs command. If you miss out the "Activate main frame" step, then you can cycle through all the windows of both frames (including the minibuffer reading the extended command) without getting "stuck", by typing C-x C-o. In GNU Emacs 25.1.50.1 (x86_64-w64-mingw32) of 2016-09-19 built on [redacted] Repository revision: 7fa96cb5ef8c8464496688e88c1b97211a820d79 Windowing system distributor 'Microsoft Corp.', version 6.1.7601 Recent messages: Configured using: 'configure --prefix /C/emacs/emacs-20160917-220655 --with-modules --without-imagemagick --disable-dependency-tracking --enable-locallisppath=%emacs_dir%/../site-lisp CFLAGS=-O3 CPPFLAGS=-D_WIN32_WINNT=_WIN32_WINNT_WIN7' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS MODULES Important settings: value of $LANG: ENG locale-coding-system: cp1252 Major mode: Lisp Interaction Minor modes in effect: shell-dirtrack-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv bytecomp byte-compile cl-extra cconv dired dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cus-edit wid-edit cus-start cus-load thingatpt help-fns radix-tree help-mode easymenu shell pcomplete comint ansi-color ring ediff-merg ediff-wind ediff-diff ediff-mult ediff-help ediff-init cl-loaddefs pcase cl-lib ediff-util ediff time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote w32notify dbusbind w32 multi-tty make-network-process emacs) Memory information: ((conses 16 129567 11696) (symbols 56 23528 0) (miscs 48 59 161) (strings 32 27309 5458) (string-bytes 1 840088) (vectors 16 16332) (vector-slots 8 472408 8689) (floats 8 199 207) (intervals 56 325 41) (buffers 976 17)) From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 21 13:48:05 2016 Received: (at 24500) by debbugs.gnu.org; 21 Sep 2016 17:48:05 +0000 Received: from localhost ([127.0.0.1]:59848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bmlcr-0000pO-4R for submit@debbugs.gnu.org; Wed, 21 Sep 2016 13:48:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33094) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bmlcp-0000os-GB for 24500@debbugs.gnu.org; Wed, 21 Sep 2016 13:48:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmlcb-00028O-HT for 24500@debbugs.gnu.org; Wed, 21 Sep 2016 13:47:58 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmlcb-00028K-E7; Wed, 21 Sep 2016 13:47:49 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4333 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bmlcY-0003kX-JA; Wed, 21 Sep 2016 13:47:49 -0400 Date: Wed, 21 Sep 2016 20:47:55 +0300 Message-Id: <83a8f1f8l0.fsf@gnu.org> From: Eli Zaretskii To: Richard Copley In-reply-to: (message from Richard Copley on Wed, 21 Sep 2016 18:23:20 +0100) Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-Debbugs-Envelope-To: 24500 Cc: 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) > From: Richard Copley > Date: Wed, 21 Sep 2016 18:23:20 +0100 > > C-x b * RET ; create a spare buffer so we can invoke ediff-buffers > M-x ediff-buffers RET RET RET > C-x 5 o ; Activate main frame > M-x ; Select minibuffer > C-x C-o ; Something not very useful happens > > At this point in the recipe Emacs is in a strange state. The cursor in > the minibuffer is solid but not blinking. There are visual changes in > the Ediff control frame as though the window is selected, but the > Ediff frame isn't actually activated. Typing C-g doesn't exit the > minibuffer (which is still reading the command for M-x). Typing a > self-inserting character does send that character to the minibuffer, > and returns things to normal. Isn't this just the normal way of having input to one frame being redirected to another? From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 21 16:10:23 2016 Received: (at 24500) by debbugs.gnu.org; 21 Sep 2016 20:10:23 +0000 Received: from localhost ([127.0.0.1]:59967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bmnqZ-0004NV-G2 for submit@debbugs.gnu.org; Wed, 21 Sep 2016 16:10:23 -0400 Received: from mail-yw0-f170.google.com ([209.85.161.170]:36268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bmnqY-0004NI-7L for 24500@debbugs.gnu.org; Wed, 21 Sep 2016 16:10:22 -0400 Received: by mail-yw0-f170.google.com with SMTP id t67so72808295ywg.3 for <24500@debbugs.gnu.org>; Wed, 21 Sep 2016 13:10:22 -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=e8Qy1TgdJi52nEHYHZgf9owIp4gjlSs9zBT2XezBYGo=; b=dUwDPTck1k5E9tvH41/5NPrc9w/jr40Rk0me7mpZ8FsAJbbbfweLWjUswRTppFabIA 5ZbOys2kzUsshwWJzCl8qoFuzxDjBkwUmL0Edd3L1N93xY8BYLoUC5R0C4ptqUTb6K// froZ+juVOyx364S3jvzRxYfnfbSvGfJRmi/OxdogsPTQ7oX1ku5YuEGnGM2LNWYsq1qh ZLVQLuO1INKuxSxHlu2/KhrN6Ei82JuUNW6q59NHp6g0pgnJoFq26SnCL3h8wjABTc0s zpNkbCegHxwuOcweNFKSe82xKp/GuYYWb/TncYMD3TMwN7F8pPFQzJINlr3FxnwGy8RA APmA== 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=e8Qy1TgdJi52nEHYHZgf9owIp4gjlSs9zBT2XezBYGo=; b=HB8l6+L9g7V6FHvbhUGrRjFu9WIbAITDCFPv244L+Md3xsjsS0Zjh5ecqphNGe6hIk A2uOJ0FEbPleeSPs2ALqR3W8uxjWmAWrrRMujbZ5sxHzJfm4NzRBAfXkySUnvjkltECJ t73n1PTOwDxbLgzDAuZWaduGQzsXdhkhAlhberccD1QqSCkofsGzQBtTwtFtryZb65pX UEyNVJYM3hPFoJIDkVJuOxYwifL/z4/6r8GKKMu9wvTlOZ1UApjzLUCN94ZEzxKcRemq 3lIddnWkH49CDZBWE1gLZJlx7Ql3W+WKLNVDQkaWv7/xTQ3mL207yaOWVKPmql616Yu2 q9hA== X-Gm-Message-State: AE9vXwMiI9tayFqxkdMe1lAtxSrG60G4y1QOGltUOHhOPfP+cqm3tlm4d3tBbMsxQTlnx2kd+1OgjCuFMswnFA== X-Received: by 10.129.128.3 with SMTP id q3mr35768649ywf.290.1474488616750; Wed, 21 Sep 2016 13:10:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.176 with HTTP; Wed, 21 Sep 2016 13:09:46 -0700 (PDT) In-Reply-To: <83a8f1f8l0.fsf@gnu.org> References: <83a8f1f8l0.fsf@gnu.org> From: Richard Copley Date: Wed, 21 Sep 2016 21:09:46 +0100 Message-ID: Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24500 Cc: 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 21 September 2016 at 18:47, Eli Zaretskii wrote: >> From: Richard Copley >> Date: Wed, 21 Sep 2016 18:23:20 +0100 >> >> C-x b * RET ; create a spare buffer so we can invoke ediff-buffers >> M-x ediff-buffers RET RET RET >> C-x 5 o ; Activate main frame >> M-x ; Select minibuffer >> C-x C-o ; Something not very useful happens >> >> At this point in the recipe Emacs is in a strange state. The cursor in >> the minibuffer is solid but not blinking. There are visual changes in >> the Ediff control frame as though the window is selected, but the >> Ediff frame isn't actually activated. Typing C-g doesn't exit the >> minibuffer (which is still reading the command for M-x). Typing a >> self-inserting character does send that character to the minibuffer, >> and returns things to normal. > > Isn't this just the normal way of having input to one frame being > redirected to another? I don't see how it is normal, so I'm probably missing something. The input to the main frame being redirected to the Ediff frame, or vice versa? Why? And why did "C-x C-o" put me in that state, be it normal or otherwise, rather than selecting one of the windows in the main frame? From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 22 11:25:58 2016 Received: (at 24500) by debbugs.gnu.org; 22 Sep 2016 15:25:58 +0000 Received: from localhost ([127.0.0.1]:60798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bn5ss-00025h-FY for submit@debbugs.gnu.org; Thu, 22 Sep 2016 11:25:58 -0400 Received: from eggs.gnu.org ([208.118.235.92]:36884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bn5sr-00025V-4I for 24500@debbugs.gnu.org; Thu, 22 Sep 2016 11:25:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bn5si-0002HR-T2 for 24500@debbugs.gnu.org; Thu, 22 Sep 2016 11:25:52 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58159) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bn5si-0002HL-PM; Thu, 22 Sep 2016 11:25:48 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1487 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bn5sg-0004yb-CB; Thu, 22 Sep 2016 11:25:48 -0400 Date: Thu, 22 Sep 2016 18:26:06 +0300 Message-Id: <83mvj0dkhd.fsf@gnu.org> From: Eli Zaretskii To: Richard Copley In-reply-to: (message from Richard Copley on Wed, 21 Sep 2016 21:09:46 +0100) Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: <83a8f1f8l0.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-Debbugs-Envelope-To: 24500 Cc: 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) > From: Richard Copley > Date: Wed, 21 Sep 2016 21:09:46 +0100 > Cc: 24500@debbugs.gnu.org > > >> C-x b * RET ; create a spare buffer so we can invoke ediff-buffers > >> M-x ediff-buffers RET RET RET > >> C-x 5 o ; Activate main frame > >> M-x ; Select minibuffer > >> C-x C-o ; Something not very useful happens > >> > >> At this point in the recipe Emacs is in a strange state. The cursor in > >> the minibuffer is solid but not blinking. There are visual changes in > >> the Ediff control frame as though the window is selected, but the > >> Ediff frame isn't actually activated. Typing C-g doesn't exit the > >> minibuffer (which is still reading the command for M-x). Typing a > >> self-inserting character does send that character to the minibuffer, > >> and returns things to normal. > > > > Isn't this just the normal way of having input to one frame being > > redirected to another? > > I don't see how it is normal, so I'm probably missing something. The > input to the main frame being redirected to the Ediff frame, or vice > versa? Vice versa. The Ediff control frame is a minibuffer-less frame, and when it is created, it specifies the minibuffer of the main frame as its minibuffer. > Why? That is how Emacs uses frame A for minibuffer input that pertains to frame B. > And why did "C-x C-o" put me in that state, be it normal or > otherwise, rather than selecting one of the windows in the main > frame? (You meant "C-x o", not "C-x C-o".) "C-x o" switches to "some other window in the cyclic ordering of windows". It does so by calling next-window, which is called in a way that doesn't limit it to return windows only on the current frame. As you yourself say in the original report: If you miss out the "Activate main frame" step, then you can cycle through all the windows of both frames [...] So what happens here is that next-window returns the window on the Ediff control frame, and Emacs then selects it, and also makes the control frame the selected frame. But because the original selected frame, when you typed "M-x", was the main frame (and we are still reading from its minibuffer), Emacs switches back to the main frame right away. And that's what you see: the single window of the Ediff control frame becomes the selected window, but its frame doesn't become the selected frame. Not sure what, if anything, could or should be done about this. Perhaps Martin will have some tricks up his sleeves. It's a corner use case, regardless. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 23 02:05:18 2016 Received: (at 24500) by debbugs.gnu.org; 23 Sep 2016 06:05:19 +0000 Received: from localhost ([127.0.0.1]:32957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnJbq-0003Ch-OC for submit@debbugs.gnu.org; Fri, 23 Sep 2016 02:05:18 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:35385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnJbp-0003CU-2c for 24500@debbugs.gnu.org; Fri, 23 Sep 2016 02:05:17 -0400 Received: by mail-pa0-f54.google.com with SMTP id oz2so36846221pac.2 for <24500@debbugs.gnu.org>; Thu, 22 Sep 2016 23:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:user-agent:mime-version; bh=dg74PcfTP33hOOAkikjDiXaOUhE8x/kOycEOcAdSvJU=; b=uXr7DtFY0ybR+vx9VuZYkavf56GqgdUP5X3EP/c3j76QbNSl9G4x/ukrBnP/FICkbM jrKumy5hlHYgAvsCPm+ENWP2CUpW6i9OOtwAxSgzgXPNxqUJ9Loxc/DWBAusXZu0ml+C YnnpvFw9nZf0DNJk9gFqQekwJuZUhqSNWGI44HgpZPBpNr/8G6lJsmCRyxhhf8/PG+BY LUMeCnOQge8w0vkMDx7UkdurG+78sC2EAhV71kUHcnP5wr8pD7uUC7/hYqiKJVkwTGgl UGTJy+plA3/QgJDR0XjmLI1EGAYyX9SeEYwZIVQf0EJP/zhaqrpd/gtK67GKHz1aLlhu kVqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:cc:subject:message-id:user-agent :mime-version; bh=dg74PcfTP33hOOAkikjDiXaOUhE8x/kOycEOcAdSvJU=; b=c5DJX/YQxepCf+1bYpAVDZYaVJ8hiVzwkHPsH2dKk8H8xPpArQ6S1j3MBnhpDEgZLg O2igCYa/cerPuHk0Hv1DHNiNqcMwltlvkaxdvmhS8ghJzdGkPyj48xUlQawz/REkCD4X 3gzcTFHH8kADX6QW+vGS/G2amFWXOfxniMNPC4X2nSBIXPicIXVXfIR9vBK8KKz5ajXN ikfTdd06BtTvLikgmsDEL6eYWW4PDXr8ignWQG9eP3t7NN37u85M95qwDBViJNDR5Gdl UR0gH/1yFPKvZGwwKrW04/1y4A/kYLE2lmZvsHiMA0t6eMczQI7cYdp2XbAD4Ly1At4Y wK/A== X-Gm-Message-State: AE9vXwPDtu8gJhuMT50e3SrlKdJmDo3svrRHSDf0yvlXJN+wEb7koVnb/yJklK3mgskbiA== X-Received: by 10.66.253.7 with SMTP id zw7mr9826331pac.25.1474610711120; Thu, 22 Sep 2016 23:05:11 -0700 (PDT) Received: from calancha-pc (57.92.100.220.dy.bbexcite.jp. [220.100.92.57]) by smtp.gmail.com with ESMTPSA id p7sm8229254paa.3.2016.09.22.23.05.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Sep 2016 23:05:10 -0700 (PDT) From: Tino Calancha X-Google-Original-From: Tino Calancha Date: Fri, 23 Sep 2016 15:05:07 +0900 (JST) X-X-Sender: calancha@calancha-pc To: Richard Copley Subject: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On Thu, 21 Sep 2016, Richard Copley wrote: >C-x C-o doesn't do anything useful when reading from the minibuffer, if >an Ediff control panel frame is present (but not activated). >>From 'emacs -Q': >;; To illustrate what C-x C-o is supposed to do: >M-x ; select minibuffer >C-x C-o ; select *scratch* window while reading from minibuffer >ESC ESC ESC ; quit >;; To illustrate what goes wrong when Ediff is active: >C-x b * RET ; create a spare buffer so we can invoke ediff-buffers >M-x ediff-buffers RET RET RET >C-x 5 o ; Activate main frame >M-x ; Select minibuffer >C-x C-o ; Something not very useful happens I guess this is a bug. It's annoying that you cannot use `C-x o' from the minibuffer. Note that, if you are in an Emacs session without gui, `C-x o' will do the right thing. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 24 15:05:04 2016 Received: (at 24500) by debbugs.gnu.org; 24 Sep 2016 19:05:04 +0000 Received: from localhost ([127.0.0.1]:34795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnsG0-0000Bw-Ar for submit@debbugs.gnu.org; Sat, 24 Sep 2016 15:05:04 -0400 Received: from mout.gmx.net ([212.227.17.21]:52447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnsFy-0000BO-5M for 24500@debbugs.gnu.org; Sat, 24 Sep 2016 15:05:02 -0400 Received: from [192.168.1.100] ([212.95.7.65]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MdoR7-1bbzCc1N4H-00Pgle; Sat, 24 Sep 2016 21:04:55 +0200 Message-ID: <57E6CE51.1040600@gmx.at> Date: Sat, 24 Sep 2016 21:04:49 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> In-Reply-To: <83mvj0dkhd.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------080505060609040202070303" X-Provags-ID: V03:K0:+B7gC+/JvrKLHFr6QCNWa2gVu+TmAN17l+S411Pzfxz8yft6Gm+ jMDfCieTeTIETbQhzT2/1KAk1fKXdHfhCh0mGcMSUIiPCbUeyYk8TfDG4gQCUu3BnBx/7is h54a6hrCn5b7oiELV1KZmwAlXer/sDXaskvfUd5N4JoX+DfIyF6xO8NsDZW43+VWfpo2b3N 5bXpY4xWV9KexlVc9poSw== X-UI-Out-Filterresults: notjunk:1;V01:K0:4rfpFKmfs78=:d2m9g59Lnr0We8gK7rAjuJ 3Hb+3+672U9dAfhVw85siRo1GMZf4dDc6c2J04gnoo6y8WmjmAX4oO1xwdPJKDXCc8yTnxznJ Ak12N/swVja2Q/jj48iMt9vLnCvLaDDLeEasNZJK3gMcE/BVbVo4o+pbYxphqN4CTVAQVbNEb v6AqnOytAGGS8J4OHylMFZ+/VGo8QrCEzXDh1Hy66xEg60MuPG7OLm0xnkfF6MudtG2Fbi31Q 1pmZe5AWeIChLMJD2AZjOQEjJqVY2TZbebMXLK7l4Op5iSrUjXbT9EO976l/KnioZiMOD+3B5 H8zub3IWqt3IXHO4p7P5fUkrRYXPdtZIX41Civig1dhywJ2UirUFM3qxGe0wvfCjhMriMeLRE 0bU+eLiM6DBXonF6+O6H+kwv/AeTw6D8iulo0u8n50dR3KQ6X5VD1Y1pA7MWKeu0Fs+u3Sh0D Qu3tmnnc6E+q6vA3LCLGEoHKRfhokDBM+qG0CJZY8saR9s/8h1b2QEKOp3lIZtNVYXolJ3fe4 dpSuublGoksklrI/cvqqUstLyxehnC3Q3XOiOHnfE9zWKrR5IW5QDB/n2fb3hCH92d4Ur9kGZ Ma88cMWizZRDNGnQ8RJJWNK0T/Rv3I3cPTrLxC/7gwH4nC2s1XZ+w+ZOyIU8HG5MvtGtkk/uS eQPXYclRepeHlLB06g0DsESua0lWkKEmCrOoCwXo4br6xjRnQVzPQPjF1kbqQ8LhzyMlkHgxp 8AAcUp6QgFtKTEMmnTfj83+9bmajlPZqYL8XGPEjhTtc13iK4Lxf66nvL/SAQ78z/iFWcOx17 OGI2f7v X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 24500 Cc: 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) This is a multi-part message in MIME format. --------------080505060609040202070303 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable A simpler scenario with emacs -Q is evaluating (make-frame '((minibuffer . nil))) followed by M-x and C-x o in the original frame. > "C-x o" switches to "some other window in the cyclic ordering of > windows". It does so by calling next-window, which is called in a way= > that doesn't limit it to return windows only on the current frame. It this particular case it does so because the minibuffer is (1) active and (2) shared by the minibuffer-less frame. > So what happens here is that next-window returns the window on the > Ediff control frame, and Emacs then selects it, and also makes the > control frame the selected frame. But because the original selected > frame, when you typed "M-x", was the main frame (and we are still > reading from its minibuffer), Emacs switches back to the main frame > right away. And that's what you see: the single window of the Ediff > control frame becomes the selected window, but its frame doesn't > become the selected frame. That would be fatal ;-) At the command prompt the frame of the selected window must be invariantly the selected frame. Try the following snippet: (defvar frame (make-frame '((minibuffer . nil)))) (define-key ctl-x-map "o" 'my-other-window) (defun my-other-window () (interactive) (other-window 1) (with-current-buffer "*scratch*" (goto-char (point-max)) (insert (format "sw: %s ... wfsw: %s ... sf: %s ... fff: %s\n" (selected-window) (window-frame (selected-window)) (selected-frame) (frame-focus frame))))) It's easy to see, trying with M-x and C-x o, once from the original and once from the minibuffer-less frame, that the difference is with the focus of the minibuffer-less frame. The selected window and the selected frame's selected window are always the same. > Not sure what, if anything, could or should be done about this. The annoying aspect is that once the minibuffer-less frame is selected, another C-x o doesn't get you back to the frame with the minibuffer for the simple reason that the minibuffer-less frame has its focus currently _not_ redirected. As a consequence, no combinations of C-g and C-x o will get you out of this mess. I attached two patches that seem to work, but without any warranty (I do not fully understand the intentions of frame-focus/focus_frame and x_get_focus_frame yet). The purpose of these patches is to keep the =E2=80=98next-window=E2=80=99 and =E2=80=98other-window=E2=80=99 mechanis= ms symmetric whenever a frame shares its minibuffer with other frames: (1) The frame.c patch changes the behavior of =E2=80=98do_switch_frame=E2= =80=99 by redirecting focus to another frame that shares this frame's minibuffer even when that other frame has no pending minibuffer activity. (2) The window.c patch simply inhibits =E2=80=98next-window=E2=80=99 to s= elect a window on a frame that has no pending minibuffer activity. Please try these patches (only one at a time because the window.c patch makes the frame.c patch moot) and tell me whether they have any bad effects. Thanks, martin --------------080505060609040202070303 Content-Type: text/plain; charset=windows-1252; name="other-window.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="other-window.diff" ZGlmZiAtLWdpdCBhL3NyYy9mcmFtZS5jIGIvc3JjL2ZyYW1lLmMKaW5kZXggMDBmMjVmNy4u YjcyOTI0OSAxMDA2NDQKLS0tIGEvc3JjL2ZyYW1lLmMKKysrIGIvc3JjL2ZyYW1lLmMKQEAg LTExNTcsNyArMTE1NywxMCBAQCBkb19zd2l0Y2hfZnJhbWUgKExpc3BfT2JqZWN0IGZyYW1l LCBpbnQgdHJhY2ssIGludCBmb3JfZGVsZXRpb24sIExpc3BfT2JqZWN0IG5vcgogICAgICAg aWYgKEZSQU1FUCAoeGZvY3VzKSkKIAl7CiAJICBmb2N1cyA9IEZSQU1FX0ZPQ1VTX0ZSQU1F IChYRlJBTUUgKHhmb2N1cykpOwotCSAgaWYgKEZSQU1FUCAoZm9jdXMpICYmIFhGUkFNRSAo Zm9jdXMpID09IFNFTEVDVEVEX0ZSQU1FICgpKQorCSAgaWYgKChGUkFNRVAgKGZvY3VzKSAm JiBYRlJBTUUgKGZvY3VzKSA9PSBTRUxFQ1RFRF9GUkFNRSAoKSkKKwkgICAgICB8fCAoTklM UCAoZm9jdXMpCisJCSAgJiYgRVEgKEZSQU1FX01JTklCVUZfV0lORE9XIChYRlJBTUUgKGZy YW1lKSksCisJCQkgc2YtPnNlbGVjdGVkX3dpbmRvdykpKQogCSAgICBGcmVkaXJlY3RfZnJh bWVfZm9jdXMgKHhmb2N1cywgZnJhbWUpOwogCX0KICAgICB9CmRpZmYgLS1naXQgYS9zcmMv d2luZG93LmMgYi9zcmMvd2luZG93LmMKaW5kZXggNzMzY2Y3NS4uNDI4ZDU3MiAxMDA2NDQK LS0tIGEvc3JjL3dpbmRvdy5jCisrKyBiL3NyYy93aW5kb3cuYwpAQCAtMjM0Niw4ICsyMzQ2 LDcgQEAgY2FuZGlkYXRlX3dpbmRvd19wIChMaXNwX09iamVjdCB3aW5kb3csIExpc3BfT2Jq ZWN0IG93aW5kb3csCiAJICAgID09IEZSQU1FX1RFUk1JTkFMIChYRlJBTUUgKHNlbGVjdGVk X2ZyYW1lKSkpOwogICAgIH0KICAgZWxzZSBpZiAoV0lORE9XUCAoYWxsX2ZyYW1lcykpCi0g ICAgY2FuZGlkYXRlX3AgPSAoRVEgKEZSQU1FX01JTklCVUZfV0lORE9XIChmKSwgYWxsX2Zy YW1lcykKLQkJICAgfHwgRVEgKFhXSU5ET1cgKGFsbF9mcmFtZXMpLT5mcmFtZSwgdy0+ZnJh bWUpCisgICAgY2FuZGlkYXRlX3AgPSAoRVEgKFhXSU5ET1cgKGFsbF9mcmFtZXMpLT5mcmFt ZSwgdy0+ZnJhbWUpCiAJCSAgIHx8IEVRIChYV0lORE9XIChhbGxfZnJhbWVzKS0+ZnJhbWUs IEZSQU1FX0ZPQ1VTX0ZSQU1FIChmKSkpOwogICBlbHNlIGlmIChGUkFNRVAgKGFsbF9mcmFt ZXMpKQogICAgIGNhbmRpZGF0ZV9wID0gRVEgKGFsbF9mcmFtZXMsIHctPmZyYW1lKTsKCg== --------------080505060609040202070303-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 28 19:21:49 2016 Received: (at 24500) by debbugs.gnu.org; 28 Sep 2016 23:21:49 +0000 Received: from localhost ([127.0.0.1]:38307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bpOAe-0005j1-Vz for submit@debbugs.gnu.org; Wed, 28 Sep 2016 19:21:49 -0400 Received: from mail-ua0-f178.google.com ([209.85.217.178]:35763) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bpOAd-0005io-DJ for 24500@debbugs.gnu.org; Wed, 28 Sep 2016 19:21:47 -0400 Received: by mail-ua0-f178.google.com with SMTP id q42so51492814uaq.2 for <24500@debbugs.gnu.org>; Wed, 28 Sep 2016 16:21:47 -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:content-transfer-encoding; bh=CXblIgXoC5g4wM69CQBBhTe/i8b0LGqkrdp2I5mrx7c=; b=S+0boo4UoI4q0hU9r/gQTJhjPcLkG62MnOF8PsSgjcY1RBl2qxLEMnLZBfSEEq6bPm ctEmZ4rMmNKyjnykTvj6w1b3Pq6QSOAC/dlGUvS8I34lldS0FwE3z3VTuoWsdQGMX2cR xSMRphz+devtkTUzJvRXG+IYBOBEHMLymMUsPWveWfkDMc2xd59CdfVTFPAO/twohn+V QHlakKGqckhjNjjUThm6e7ApSsM+n9u9IM521vXp/I/G2BSXOToEWwpyDu5tA6LCTTVB 73EEogDSMXyIrXsE+pa+wk/8QuemKCtJs01P6QzamN4hQgeytogc7+k6X07nsBNKjeHd /DaQ== 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:content-transfer-encoding; bh=CXblIgXoC5g4wM69CQBBhTe/i8b0LGqkrdp2I5mrx7c=; b=kFEdqoRIXhb0GQIg/94AJEIqvR2oXLZp0B8FNlGVa6NHVY3Xr5VfCMhBbm2pftW7wS 7BOd2WgGQtqvNT1Hdce3zH66AImkweivPYcYuvy0G4IbtT8TaN3UjEDUnb/Jmfnfbc4M J0M5ys6pLClRyHzivw/DeHFYzM3gMbax2xpPxiwmt2pXhXpiOEgYF3KGSJ3YaP0lca1n lhYwcw0bO1N6XX01nkOhEUj/T0POLsTABMBACWH/M4m2nKhzCFEhpgRw3EE6V6Ad9re0 3ZVlJ6q63h7Ifd2cmSVC3s3lwWycQg+QekWUt5vKTqBL8DZY1xJn5DL22ySMhcxYwGmq +c3Q== X-Gm-Message-State: AA6/9Rk4xlOX64ub5WbTD6Z9bM5MaP0pmAB0OuoGRrrJOKqXxLSBupd6fiBTqGQd88t4BBTvSxIgzUdicWgdcA== X-Received: by 10.159.40.193 with SMTP id d59mr8516504uad.80.1475104901658; Wed, 28 Sep 2016 16:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.176 with HTTP; Wed, 28 Sep 2016 16:21:11 -0700 (PDT) In-Reply-To: <57E6CE51.1040600@gmx.at> References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> From: Richard Copley Date: Thu, 29 Sep 2016 00:21:11 +0100 Message-ID: Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: martin rudalics Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 24 September 2016 at 20:04, martin rudalics wrote: > A simpler scenario with emacs -Q is evaluating > > (make-frame '((minibuffer . nil))) > > followed by M-x and C-x o in the original frame. > >> "C-x o" switches to "some other window in the cyclic ordering of >> windows". It does so by calling next-window, which is called in a way >> that doesn't limit it to return windows only on the current frame. > > It this particular case it does so because the minibuffer is (1) active > and (2) shared by the minibuffer-less frame. > >> So what happens here is that next-window returns the window on the >> Ediff control frame, and Emacs then selects it, and also makes the >> control frame the selected frame. But because the original selected >> frame, when you typed "M-x", was the main frame (and we are still >> reading from its minibuffer), Emacs switches back to the main frame >> right away. And that's what you see: the single window of the Ediff >> control frame becomes the selected window, but its frame doesn't >> become the selected frame. > > That would be fatal ;-) > > At the command prompt the frame of the selected window must be > invariantly the selected frame. Try the following snippet: > > (defvar frame (make-frame '((minibuffer . nil)))) > > (define-key ctl-x-map "o" 'my-other-window) > > (defun my-other-window () > (interactive) > (other-window 1) > (with-current-buffer "*scratch*" > (goto-char (point-max)) > (insert > (format "sw: %s ... wfsw: %s ... sf: %s ... fff: %s\n" > (selected-window) > (window-frame (selected-window)) > (selected-frame) > (frame-focus frame))))) > > It's easy to see, trying with M-x and C-x o, once from the original and > once from the minibuffer-less frame, that the difference is with the > focus of the minibuffer-less frame. The selected window and the > selected frame's selected window are always the same. > >> Not sure what, if anything, could or should be done about this. > > The annoying aspect is that once the minibuffer-less frame is selected, > another C-x o doesn't get you back to the frame with the minibuffer for > the simple reason that the minibuffer-less frame has its focus currently > _not_ redirected. As a consequence, no combinations of C-g and C-x o > will get you out of this mess. > > I attached two patches that seem to work, but without any warranty (I do > not fully understand the intentions of frame-focus/focus_frame and > x_get_focus_frame yet). The purpose of these patches is to keep the > =E2=80=98next-window=E2=80=99 and =E2=80=98other-window=E2=80=99 mechanis= ms symmetric whenever a frame > shares its minibuffer with other frames: > > (1) The frame.c patch changes the behavior of =E2=80=98do_switch_frame=E2= =80=99 by > redirecting focus to another frame that shares this frame's minibuffer > even when that other frame has no pending minibuffer activity. > > (2) The window.c patch simply inhibits =E2=80=98next-window=E2=80=99 to s= elect a window > on a frame that has no pending minibuffer activity. > > Please try these patches (only one at a time because the window.c patch > makes the frame.c patch moot) and tell me whether they have any bad > effects. > > Thanks, martin Thank you! With patch (1) the focus can get stuck. Having saved the "my-other-window" example above as "x.el", from "emacs -Q", M-x load-file RET x.el RET ;; Creates and selects a minibuffer-less frame. ;; Call the initial frame "frame 1" and the minibuffer-less frame "frame 2"= . C-x b window2 RET ;; Select named window in frame 2 for clarity. C-x 5 o ;; Switch to frame 1 M-x C-x 5 o ;; Switch to frame 2 C-x o ;; Select window *scratch* in frame 1. C-x o ;; Select minibuffer. C-g ;; Quit M-x ;; Selected frame is frame 2 and selected window in frame 2 is "window2", ;; but focus is still redirected to frame 1 (selected window now "*scratch*= "). xyzzy ;; Characters are inserted in *scratch*. No amount of switching between frames 1 and 2 changes the focus redirection, but clicking inside a window on frame 2 does remove the redirection and get things back to normal. I'll try patch (2) later. It sounds logical to me. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 30 04:33:00 2016 Received: (at 24500) by debbugs.gnu.org; 30 Sep 2016 08:33:00 +0000 Received: from localhost ([127.0.0.1]:39254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bptFc-0007kL-4W for submit@debbugs.gnu.org; Fri, 30 Sep 2016 04:33:00 -0400 Received: from mout.gmx.net ([212.227.17.20]:62065) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bptFZ-0007k4-Kt for 24500@debbugs.gnu.org; Fri, 30 Sep 2016 04:32:58 -0400 Received: from [192.168.1.100] ([212.95.7.20]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MIuft-1bnyNH0iYT-002XrD; Fri, 30 Sep 2016 10:32:50 +0200 Message-ID: <57EE232E.4090301@gmx.at> Date: Fri, 30 Sep 2016 10:32:46 +0200 From: martin rudalics MIME-Version: 1.0 To: Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:iL81CytWZPHo/yqOvniHSdDP3aWAWhfaz9vjXc3fpm4o+IpbgtK RcY/CT7EXQl3caRGuw8KEGAiNz4U+UAnP6VPWT1eWNINZ0qd9FOSN+RVy0TNVIbHkT/edZk f1XkIYvD0mTKiwcPpv16YNWvgJjJqPnevDRgA58RWaD0GSE17p3cSEaXMwDbcMjUPo6hOf4 5UZdjBfE4aOINyAGRfWRw== X-UI-Out-Filterresults: notjunk:1;V01:K0:WIwP/GvLYxM=:tGAZ7/2nN1DUZU7PoEdX6X LLcpFqI3rZUfQlqm4p6ZNG0E7NkOv68VwqfBIoRFE8R2wpvMeQGN+tE51gu2kY7iIzcCSdeBe C4cHg8HW8eJnn6eeXvq82ERCQENYHHFufVMJ+C5HHLeRe+Npj9jqAfVAsLw2dyofZcjX95fKI WiuyLvhZbcpD0GzyXR3GEx7PNgp7sYQeqM/OYroe5rPwgRt73uRVcb1heop+h4Gf/AY2LIZx8 jYgB0yv0I5nOHP+2qhpbFn5JbdADng0SzJSGHUd4M024TdBneRXNWYA9SgB+Sa0nOS9CdK/YJ 934fE4j2uelQMfX7UFV3XmVhQ75G4vPvSmCKnYjUpHY46ClVpi+0eu/ST4uuFRmwt4n5oDkEh pUCZYTW88m4KS9Ihg85y9VkrDGlX8P3kL3Dt0Bp4O2FDuMF6J6L9lOOuuoqdguXCdwEZgUJ+O LO2QNJsA9cdEiplx25EcJCxjBzKhXhAt3mHtI50FsFDyZgB5ENkE6i3lziprTIVOI5DzhGhmb Nd/8/AsRZW6BSRSvhzafGEQT5HB3NgXECe3cRa0fVy4NhLJfKSkSuh39XLHZMpq//ogV4GUoj NSgcsA4c0MK7QHaD/F0rrUTGksro7Tqb9cqA970HJL1yTv0VA585hrl2MwqDtrg1zjiY/iXG4 y+EGti6PudrP8Nqr9gHY0LNOjf2bnmI2zOBXDclLo0lpEAO+rwyHCGaiTH/DHc1qF+0lCsDAM 2RO5v4tQDnhxNtAfGs3YdFCF37V6WvwCIxP4du0e9COv4jP8w2XoqLjR3KlwwTHhmF5wwVcvb uILhioLSSqXEHDL14mIU/Azt2aeuw== X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > With patch (1) the focus can get stuck. Having saved the "my-other-window" > example above as "x.el", from "emacs -Q", > > M-x load-file RET x.el RET ;; Creates and selects a minibuffer-less frame. > ;; Call the initial frame "frame 1" and the minibuffer-less frame "frame 2". > C-x b window2 RET ; ; Select named window in frame 2 for clarity. > C-x 5 o ; ; Switch to frame 1 > M-x > C-x 5 o ;; Switch to frame 2 > C-x o ;; Select window *scratch* in frame 1. > C-x o ;; Select minibuffer. > C-g ;; Quit M-x > ;; Selected frame is frame 2 [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.20 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.17.20 listed in wl.mailspike.net] 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.20 listed in dnsbl.sorbs.net] X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > With patch (1) the focus can get stuck. Having saved the "my-other-window" > example above as "x.el", from "emacs -Q", > > M-x load-file RET x.el RET ;; Creates and selects a minibuffer-less frame. > ;; Call the initial frame "frame 1" and the minibuffer-less frame "frame 2". > C-x b window2 RET ;; Select named window in frame 2 for clarity. > C-x 5 o ;; Switch to frame 1 > M-x > C-x 5 o ;; Switch to frame 2 > C-x o ;; Select window *scratch* in frame 1. > C-x o ;; Select minibuffer. > C-g ;; Quit M-x > ;; Selected frame is frame 2 [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.20 listed in list.dnswl.org] 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.20 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.17.20 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) > With patch (1) the focus can get stuck. Having saved the "my-other-window" > example above as "x.el", from "emacs -Q", > > M-x load-file RET x.el RET ;; Creates and selects a minibuffer-less frame. > ;; Call the initial frame "frame 1" and the minibuffer-less frame "frame 2". > C-x b window2 RET ;; Select named window in frame 2 for clarity. > C-x 5 o ;; Switch to frame 1 > M-x > C-x 5 o ;; Switch to frame 2 > C-x o ;; Select window *scratch* in frame 1. > C-x o ;; Select minibuffer. > C-g ;; Quit M-x > ;; Selected frame is frame 2 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). > and selected window in frame 2 is "window2", > ;; but focus is still redirected to frame 1 (selected window now "*scratch*"). > xyzzy ;; Characters are inserted in *scratch*. > > No amount of switching between frames 1 and 2 changes the focus > redirection, 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? > but clicking inside a window on frame 2 does remove > the redirection and get things back to normal. What was abnormal before? > I'll try patch (2) later. It sounds logical to me. martin From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 30 14:14:26 2016 Received: (at 24500) by debbugs.gnu.org; 30 Sep 2016 18:14:26 +0000 Received: from localhost ([127.0.0.1]:39966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bq2KI-0008J8-AH for submit@debbugs.gnu.org; Fri, 30 Sep 2016 14:14:26 -0400 Received: from mail-vk0-f53.google.com ([209.85.213.53]:36349) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bq2KG-0008Iv-7k for 24500@debbugs.gnu.org; Fri, 30 Sep 2016 14:14:25 -0400 Received: by mail-vk0-f53.google.com with SMTP id y190so79758373vkd.3 for <24500@debbugs.gnu.org>; Fri, 30 Sep 2016 11:14:24 -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=RG7XCRp3sle54l9MQdBmhC8e4qxwKqCHsra8NZRxXw8=; b=lPhvTX2t9MFMp1eu2kAsC3+pQP+nVJsnUsCvL6WT1Jkk8LButiW8XMLdt8Qu+LNTms Lcv7H7ppOZr2AWGbRU2qBpPh3MaFWmpYNM2FThb6TggnxzbOpJkoQcigyO+HQd106EY+ yBJgKps0L2TNOPXerb001zc0Kt8Dbota7VqmM8ji3/q/SOWV4u5g4nU1lLYzk9p4HFbs 3iBdoR8aOLK12ch1E9WrJwbccv1CIuHFCsk3rkTy9Ub/1sqeSAnmo9GOki3+nYo/egxE 10vfoOnPIQ1tAfuUNc2/6PlYMVJonPoF5tCPC6Flyw/q1+0fBjVBaYBwmduMJQDLZQ65 bWMQ== 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=RG7XCRp3sle54l9MQdBmhC8e4qxwKqCHsra8NZRxXw8=; b=XT2EOpDl4Od4bHzb6r/u3bIxKmv/lFPublSN4Ev+Jqevuf0fy0j9Pn0b/gX6RL1lcA 26fs+7yss2/ckep/fUICr1+PsXAy2ujrsh66JnXkU02HVKmw+gu/au7jZV+A98T7yTDR AohQlzAwxhEA/n3l+r7DrWbddVTvxMCh3Q0+ztBAWsyBBiqtt7dkO18dcPknwGMMI2wm aoGbf4P+G/An95mxHA9UwuefucWKuCNyC8nXwxIm8SUHlH2V6fHcbBevyPxa4+18nqaq nKWXBwPdUCh45+l8z2yJMMBlNqrvcnQhymli78z0PmaCz9V97E+KGUhjVzm3TNUTrcpL +k6g== X-Gm-Message-State: AA6/9Rm63EsSWSs1sEZqzbriCTME2ywhLjAcwhEDoIdxGTC9hSvij8b4SwTQT387v0YeWfojrGAK7gk5sYRhSA== X-Received: by 10.31.109.195 with SMTP id i186mr6481174vkc.105.1475259258804; Fri, 30 Sep 2016 11:14:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.1 with HTTP; Fri, 30 Sep 2016 11:13:48 -0700 (PDT) In-Reply-To: <57EE232E.4090301@gmx.at> References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57EE232E.4090301@gmx.at> From: Richard Copley Date: Fri, 30 Sep 2016 19:13:48 +0100 Message-ID: Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: martin rudalics Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 30 September 2016 at 09:32, martin rudalics wrote: >> With patch (1) the focus can get stuck. Having saved the "my-other-window" >> example above as "x.el", from "emacs -Q", >> >> M-x load-file RET x.el RET ;; Creates and selects a minibuffer-less frame. >> ;; Call the initial frame "frame 1" and the minibuffer-less frame "frame >> 2". >> C-x b window2 RET ;; Select named window in frame 2 for clarity. >> C-x 5 o ;; Switch to frame 1 >> M-x >> C-x 5 o ;; Switch to frame 2 >> C-x o ;; Select window *scratch* in frame 1. >> C-x o ;; Select minibuffer. >> C-g ;; Quit M-x >> ;; Selected frame is frame 2 > > 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. The fact I was attempting to express is that the activated window at the window-manager level is frame 2. >> and selected window in frame 2 is "window2", >> ;; but focus is still redirected to frame 1 (selected window now >> "*scratch*"). >> xyzzy ;; Characters are inserted in *scratch*. >> >> No amount of switching between frames 1 and 2 changes the focus >> redirection, > > 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, and that can't be changed by typing Alt-Tab (which on this Windows system is not passed to Emacs but activates a different window), nor by clicking on the non-client area of frame 1. In fact I hadn't tried C-x 5 o. That does fix things. >> 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. >> I'll try patch (2) later. It sounds logical to me. > > martin From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 30 14:21:48 2016 Received: (at 24500) by debbugs.gnu.org; 30 Sep 2016 18:21:48 +0000 Received: from localhost ([127.0.0.1]:39970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bq2RQ-0008UK-6E for submit@debbugs.gnu.org; Fri, 30 Sep 2016 14:21:48 -0400 Received: from mail-ua0-f178.google.com ([209.85.217.178]:32884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bq2RN-0008U7-R6 for 24500@debbugs.gnu.org; Fri, 30 Sep 2016 14:21:46 -0400 Received: by mail-ua0-f178.google.com with SMTP id v7so27221559uaa.0 for <24500@debbugs.gnu.org>; Fri, 30 Sep 2016 11:21:45 -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=EUWZxVLzqymwndeLAVHgvQj714vkU81gVniFCh/WnOA=; b=MVxiUF/lrul9DPAyfxEl3XskXzNI0m1t3jsXB54lY7ztXpGcdVPVM5172Frfuf3SFD DdNw55ZO83h9OazVsXdfSUaYZh+fsiK/TxMAsP70lvprK0JoDD92B4ULFdMn/XAONBTd DJdNk4cozf+740VdqEXVg4cZHfm3tN++MjmPVQZ7K57sQOXqF7WqEd7wSN5YXYUCTO1y qstRg+ethIYmN2Sm0DJ4u3yQzESMC66jsMAd38la1fhLEoLw5JX4pMGxeNxWykhwKA/K tyJ36Uf+vfUQDU+ZnsEPI750XQbSqGjuu2VQV3JuNqXh30IXIsWUNUUJvGnLQeOawtra GNZw== 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=EUWZxVLzqymwndeLAVHgvQj714vkU81gVniFCh/WnOA=; b=Pr/sgAQewdocxE2LUBy2GZPR4Lol9e8+Z96TffLeksNjjmh0kMnpynhhX4qFBzID7M H0Ou+hGd3D4L+8N5FcADpZ4k4UyFAha7gk+oi/NjlJx3lXN9o1GxI94In/y3TNdpLUik +OjMLVLG8I3MsGmHGJAETT/T5oZjjmd/gLOTp8r9Hs5TUiBz4Eq3LQXw+YXnQld1f+Fv IukiJkvV63ryQSnbaVHseDX7gA2V+Wobg4XmTSYkFKBK6TJGzi6YKK97xiCAXIrmMU+i Uvx0SFkcMElm98JW3BvtHrUEpq9+8kYnobn0Y90OR/OJnBqDVSqSRaRfiJAjY9JFPYIp pwcg== X-Gm-Message-State: AA6/9RlU8a3/hQMQ+dgsd96eVyQj3xgoJZFNLW0PSVSPvKkmYTWZ7ZtOJwtgiLsohcKujSKKJC0skNERUPIOww== X-Received: by 10.176.5.233 with SMTP id e96mr6165508uae.91.1475259700387; Fri, 30 Sep 2016 11:21:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.1 with HTTP; Fri, 30 Sep 2016 11:21:09 -0700 (PDT) In-Reply-To: References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57EE232E.4090301@gmx.at> From: Richard Copley Date: Fri, 30 Sep 2016 19:21:09 +0100 Message-ID: Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: martin rudalics Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 30 September 2016 at 19:13, Richard Copley wrote: > On 30 September 2016 at 09:32, martin rudalics wrote: >>> With patch (1) the focus can get stuck. Having saved the "my-other-window" >>> example above as "x.el", from "emacs -Q", >>> >>> M-x load-file RET x.el RET ;; Creates and selects a minibuffer-less frame. >>> ;; Call the initial frame "frame 1" and the minibuffer-less frame "frame >>> 2". >>> C-x b window2 RET ;; Select named window in frame 2 for clarity. >>> C-x 5 o ;; Switch to frame 1 >>> M-x >>> C-x 5 o ;; Switch to frame 2 >>> C-x o ;; Select window *scratch* in frame 1. >>> C-x o ;; Select minibuffer. >>> C-g ;; Quit M-x >>> ;; Selected frame is frame 2 >> >> 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. > The fact I was attempting to express is that the activated window > at the window-manager level is frame 2. > >>> and selected window in frame 2 is "window2", >>> ;; but focus is still redirected to frame 1 (selected window now >>> "*scratch*"). >>> xyzzy ;; Characters are inserted in *scratch*. >>> >>> No amount of switching between frames 1 and 2 changes the focus >>> redirection, >> >> 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. > and that can't be changed by > typing Alt-Tab (which on this Windows system is not passed to Emacs but > activates a different window), nor by clicking on the non-client area of frame > 1. > > In fact I hadn't tried C-x 5 o. That does fix things. > >>> 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. > >>> I'll try patch (2) later. It sounds logical to me. >> >> martin From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 01 04:44:53 2016 Received: (at 24500) by debbugs.gnu.org; 1 Oct 2016 08:44:53 +0000 Received: from localhost ([127.0.0.1]:40246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqFuf-0000th-5C for submit@debbugs.gnu.org; Sat, 01 Oct 2016 04:44:53 -0400 Received: from mout.gmx.net ([212.227.15.19]:52312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqFud-0000tT-4B for 24500@debbugs.gnu.org; Sat, 01 Oct 2016 04:44:51 -0400 Received: from [192.168.1.100] ([212.95.7.116]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MLOMM-1bphg83Ryc-000fo7; Sat, 01 Oct 2016 10:44:42 +0200 Message-ID: <57EF7776.80703@gmx.at> Date: Sat, 01 Oct 2016 10:44:38 +0200 From: martin rudalics MIME-Version: 1.0 To: Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57EE232E.4090301@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7/z69nqKmtNZ4AkkDkiImN7H95OvZmYkkAeAlDii8KtGc5eS/+z 7Dr3/uI4kgjDrNppO4BjJlRmPao5Z5pLHutTMNXOiZ0lcGAbBnr2M7ZBv+eHhefUKrhEpwS jwD9tcVm2Br6Motv8Zj2SsDihkrgtds0I0fccZO0nT1X1SQQLAAdXdM6mxUxjAWPzGzqEjN UhN5uCyHpYIH1CJPSIq0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:AN4fCk4qkCo=:Sv3SCKBhkU92IDLCG1y2tE Wb3mG3823OliV8YakA+6rPbpKtrz6sIkeUQ3GoJkG2zA+10rsHZbjZ3RSJniZshknqAU9Zvgy +zwHb8fb6Yz+yjkKrw5n4XMOy5NgvONhKWwux1JxTskPtvkfjq6/Or8ZZphtVgMgspjNfQVdT JsGxsXJLqT1KQtG6UleidkG3MdzMepuusTRXWMesIMuLUWjVwwj/gBg2dF8TapHXiaeDq1H0v tmJhpHwOBIsMgJ+f6Boh9JwsNZV9VfkeurdHOIum4SGTzvDOwUWrYOEJ4xo6u3GHSsAAlJbhH OB2lISsgPxyhp6ZLPsHeTdCnWBvneraafCxuXTXaX4ylUxEBxRMfRm7hlmOD8WNpYK51b/8Mr v+2mNKzqjHavMT5PkOKEEJ0pfd3TIfvKIdcU28TnrAl94pdTqqsATCmLkT9MEw1y/SdxJYjIs jkHur6zG1suVq1fB4dwPKtP4xQ+/8ZcC3qWVRl+irVWSzQ9s1qtEriOqXvNZWVX/TzDU4SVl5 5ECjJrrRGDif4VzsH9TbmjFx5ITxOr9N7tpFhrYcGL+n5EIeT+2P7yHSaOEUViJ7fGE4OnMAh 5kwVBJYAh5RCAR7ICl03meGdSE11AnIEXCTry9wLFORbC+JwYeAmvcZk9+ByUM06sKoxFlc7d hRV9vzMyxN9v1balv14infY4aUEXnhSs/836r+MJwfr1H5o89IH/D1+AvuSt0WsoDGNGsAq9Q 1qaJlxHk3IkN57MnIMCVKo7WZFGalFRqRSyi0sux7OHFwU8oLMLtd1XG7icK8y5OtDF5EcgaG 2JAQ29U9XxGKZddxQtqSERBI11NtQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> 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: Is there anything in your scenario that contradicts what has been written there? > 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. 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. 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. > > 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? > (which on this Windows system is not passed to Emacs but > > activates a different window), Which one? > nor by clicking on the non-client area of frame > > 1 But you already are in frame 1. What should that click accomplish? > In fact I hadn't tried C-x 5 o. That does fix things. Anything doing C-x o repeatedly wouldn't fix? >>> 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. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 01 06:30:44 2016 Received: (at 24500) by debbugs.gnu.org; 1 Oct 2016 10:30:44 +0000 Received: from localhost ([127.0.0.1]:40319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqHZ6-0005Dv-3R for submit@debbugs.gnu.org; Sat, 01 Oct 2016 06:30:44 -0400 Received: from mail-vk0-f53.google.com ([209.85.213.53]:35041) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqHZ4-0005Dh-8D for 24500@debbugs.gnu.org; Sat, 01 Oct 2016 06:30:42 -0400 Received: by mail-vk0-f53.google.com with SMTP id 192so124413058vkl.2 for <24500@debbugs.gnu.org>; Sat, 01 Oct 2016 03:30:42 -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=YkdNrWIY1MeG2cU25CHkTJmHa/1byUV69M8vZZhYAZ0=; b=0C3FtrPInEua+ydr1GCFwmgCnNVvEjNYLC6FtxlGaCzUsjc81op59EdLEvVv6ExQB1 dkScpB6b8x4s7yB9NeSTfPFgzbuLZMH4zqHiOqjJ2L9FPsn3kXgV2I5CCfVNe/j6BdP9 GBe22SJdYmFPTbEJmOkdJWkh8+PUMx0GbbxuZItpELR0NUfLGbvAXvkVsTikWhGwsikd PZOBPiEUIx6D7k7+eJQMg5x6Ei3bMqihcU3AOeheue4/yes58Z2DAkVAEqPEtAlOsair bM2X2NEJXolXxRnlP7bmR0LLWoWGJl/tnmnNSTEd5oJ3LNKBiM70/wG/lH7/sReTatpD 4u7w== 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=YkdNrWIY1MeG2cU25CHkTJmHa/1byUV69M8vZZhYAZ0=; b=TEX0Np0+uwWlu8gTw0OJ/aZQCT/L3qLqZyNV3dtjfOpmEDIPKS9HryXLBefccK/p38 o9uM2HjZQTIW0Rx/j77hZd8L5oNLISWFtpNv0VYbacdmbl9yDHEtBCTcOlw5222Ig5u0 hkYJfr7ceuqaUrUlu2E2Jj0yCEy9+Sg6EAkCOfrjKKvo15D6tb3+RN0vDvEiiFWM7DBW u/UXtV1PAjcGGX2C2YdW3xUlRsEpDgz6GW3pSO7MHPvrFJKdF8VPaIaFdNwwzzLtT/L7 zLwrHXR1bjErtyjrIPQXz9IJZ0G++MI+ZgrObQ+JrP5eD/J7/JV/XsYcyveHnyde6M8T QaCg== X-Gm-Message-State: AA6/9RmK+zvigeJHsqJiWW2a7WIvp3Wx74uBTeODnYKeupQ1u5lCgDihoSrqScUF6TifpoI7I3mgAEqJ6lkF2w== X-Received: by 10.31.109.195 with SMTP id i186mr8529988vkc.105.1475317836636; Sat, 01 Oct 2016 03:30:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.1 with HTTP; Sat, 1 Oct 2016 03:30:06 -0700 (PDT) In-Reply-To: <57EF7776.80703@gmx.at> References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57EE232E.4090301@gmx.at> <57EF7776.80703@gmx.at> From: Richard Copley Date: Sat, 1 Oct 2016 11:30:06 +0100 Message-ID: Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: martin rudalics Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 01 08:29:38 2016 Received: (at 24500) by debbugs.gnu.org; 1 Oct 2016 12:29:38 +0000 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 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 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) MIME-Version: 1.0 Received: by 10.159.40.1 with HTTP; Sat, 1 Oct 2016 05:29:00 -0700 (PDT) In-Reply-To: References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57EE232E.4090301@gmx.at> <57EF7776.80703@gmx.at> From: Richard Copley Date: Sat, 1 Oct 2016 13:29:00 +0100 Message-ID: Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: martin rudalics Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 01 09:09:12 2016 Received: (at 24500) by debbugs.gnu.org; 1 Oct 2016 13:09:12 +0000 Received: from localhost ([127.0.0.1]:40402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqK2R-0002BQ-U7 for submit@debbugs.gnu.org; Sat, 01 Oct 2016 09:09:12 -0400 Received: from mout.gmx.net ([212.227.17.21]:56405) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqK2P-0002BC-Tj for 24500@debbugs.gnu.org; Sat, 01 Oct 2016 09:09:10 -0400 Received: from [192.168.1.100] ([212.95.7.35]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LwF9u-1arA800JB8-0181e4; Sat, 01 Oct 2016 15:09:02 +0200 Message-ID: <57EFB568.7070305@gmx.at> Date: Sat, 01 Oct 2016 15:08:56 +0200 From: martin rudalics MIME-Version: 1.0 To: Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57EE232E.4090301@gmx.at> <57EF7776.80703@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hNy8yyn3FpCM76P0EGj0rYRhWUOIBIupH7NPL4AY7/TQ1mmx1pW 9E0D0W9akkbKJzgky+NS4HA+mAOzvkf/z9p7O+Qd8rd7YYSq9n+bXaIAT26LWvSrwuQWTLl ++Vz/fSj7C7Ef/5txGFreF1+f3m9rUCWt+Krj3Qzm1RxvcTMG6yve62hQnAvBiUzOS90g6P N0PdLBXn8N2lJo8A3lvtw== X-UI-Out-Filterresults: notjunk:1;V01:K0:hF6WGPL23Vo=:lLT/SxHs1KShgr4eD+W2UQ xWL8r4yWkmyyqGtHO5W9ci+iVzLytyJ1/1GoYk2O5mUxOy8hYpmpkMIvxqen6Sxi84V4hCCdc byz7v5wGrknViX+ilxi+eBzQ1scq5i5j0+uqJ8pNRc1ajesBWZlNl+rXVhTrMd8PwQJm5GiGA HpBVpnHMgB117O60XvZ0hg1uNu0OKMOnshy7zlegW1m0QFKCBHBs1IqciUCxMZAH2N+GyT+VH Z3g12ePYeQgxQkgeIwOMWP2bk5v986bcOnb8WqqE6hnQpobt8FUsWLB1RN2bJpR+SjOIF9m6+ 8RzCllNYqMfMyclxnrRsJfDhDOAJT7AW0YqMOjpSLInNRGX38dfL9jabPd1ii4lQKi5gdDp6i wudWiKuz8sjPEVmN5w6h4U0s5UTrGpULmyDFujK7BGi49piJZFEJ4RuCJj3pKj8u1gXKFXTJm YDJoimQzVe66YvvExiTI4QvU/JlMn7f52v8WeGwj85s+Qdn3exIOOmDbgu8PRqLwQz8YCuS5A N62f/TSlZQbPBNR6NI++ky7N2kt4ZorcvqEX2/D1ovih6DPdvqrTStGPe115jtnB0ykvdPv8/ OIrWnVWwPej6Kpd43QslL7MxV0pZ8dODKaDiw8rIKil2sRHyhx4BjulTzIDjYtjOQwjfuWMCg fEPm/Fr3XRfMuUdB+FPqzl7ZTxrtbYdv8Bfqem04eN6MboIQW2547uOFdnGMyPOIL51e7n3+Z jqyLofuETcdbT9SFkg1pIsLFChCGz0aCO+v06uvpJf3XW5c12/eXgF5p9BAMuMHdfdHMIHA3c o8hJDi4iG6jB92KoUZ/NQeGaQDgZQ== X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> 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. [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.35 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.17.21 listed in wl.mailspike.net] X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: >> 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. [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.35 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.17.21 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record >> 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); } } 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? 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. Now I do C-x o again. This selects the minibuffer window on F1. Typed text now appears in the echo area. > 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. > * 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? >> 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. >> 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? > 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. > 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. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 01 09:09:16 2016 Received: (at 24500) by debbugs.gnu.org; 1 Oct 2016 13:09:16 +0000 Received: from localhost ([127.0.0.1]:40405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqK2W-0002Bh-8i for submit@debbugs.gnu.org; Sat, 01 Oct 2016 09:09:16 -0400 Received: from mout.gmx.net ([212.227.17.20]:64808) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqK2U-0002BI-VA for 24500@debbugs.gnu.org; Sat, 01 Oct 2016 09:09:15 -0400 Received: from [192.168.1.100] ([212.95.7.35]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MN604-1bsVtU13TE-006gKJ; Sat, 01 Oct 2016 15:09:08 +0200 Message-ID: <57EFB570.7010409@gmx.at> Date: Sat, 01 Oct 2016 15:09:04 +0200 From: martin rudalics MIME-Version: 1.0 To: Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57EE232E.4090301@gmx.at> <57EF7776.80703@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VfQ/LSDMzieh9sPDIHLTLzv9a9MOEdtLUbWBT2bbw6HOH4yIgRf X9G4pCaYeNAWjZ8/F0ifF/5+7Jgy9Q7G+vyzUXjXAURDch/nLfPFfmBqBCPe9faJ/3zHlcy kZbknu8Dv5L8ic6xeUg4USfMKJFUs5uqxV+IWEvizTKAb8UiYsWklQTZLivd09qAKJIEFaq gXGBw8h9/KAH1fM2q6Zcg== X-UI-Out-Filterresults: notjunk:1;V01:K0:BkYKxos93VE=:clWIEod2zamv7WRsR1zEke J5HW5gWyF2THzBn+TYM9DlYFuGRcJwGmsycb6Q0i2j95SBs33av6RnQBGDxHOyKKqk2cCbm6W 865M+VVNKQJsZ2GvFrTxdtdUkEvIKkS3cfyhcq6XSbRDMBkCicIWUr2y9GpVJTodatO5X9GRS sn5/qWFeaiyvVYYM9GSzpXV8U3oBtik4CVfhhBxwSQRW2XGnKDE5Q0++6cNXIlcE9uFFlVhef bFlVKpQ2cDYdnePuibFPT/psoYqy3en6GJHZzZHP0xN7zo7xVOP8peyGwmJg0HcmNLJ4q7kas 1wlwMaJAnwK6jxGTxS20IN46IT64SCXxgSK0raTeUb7TA35pbPqkvWvelaaaojNaaOxNNCsEV iVr4E3pF5Ej+lkAjebhR90y/YB7TkGt6Rh24xIBdLPaDOZOFIprLyYdrq1+z6d/lD3mPPLrT9 bG8+GSrl1nyJiMl9hWzoDQR+GHP/rEqJqEWV1cPCuxTFMtOy6/W2O5vncq5LJ309cQ/fVbtEe Ecoe4wjzlEMJau8kNIaPZEZ0UkkADm5QyvazbsRVPC7fihln9AtfEAO25dCe9tMv1UzsHikHA aFKzBdbvZg1N1b/oJL0+/2RX2Tf1HFzM2lnVITejKH1UCwG9uaeZ5/KlC/4glTuSj3j+uddb5 AuyT4Tw4lP3MMjM2xvb4MMdIncuiTV1JY5xfccx5IwcUuSTEAlAj5/G2pk5FGcltdREitiGOY aF180l3BbdNn61dNlBnG8iSLPcRSU1EZ2s+Tb6z9NQ+sL30fMo6vp+ofkf90Hm5k+nj0W5ZQX o+u0vH28uY/Qqg/SYLaE9UMxitzDQ== X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > 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 [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.35 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.20 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.17.20 listed in wl.mailspike.net] X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > 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 [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.20 listed in list.dnswl.org] 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.35 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.17.20 listed in wl.mailspike.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > 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 So far we've been talking about what happens when you hit C-x o and C-g has not been reached yet. Obviously C-g cancels the entire minibuffer indirection setup and from then on C-x o will continue to stay within the frame where it was typed. This is the standard behavior and I obviously get the same as you until here. > 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 abnormal indeed and I can't observe that here. Whenever I click on a title bar or within a window, the associated fame gets selected and input focus and all typed text goes there. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 01 10:54:38 2016 Received: (at 24500) by debbugs.gnu.org; 1 Oct 2016 14:54:38 +0000 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 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 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) MIME-Version: 1.0 Received: by 10.159.40.1 with HTTP; Sat, 1 Oct 2016 07:54:00 -0700 (PDT) In-Reply-To: <57EFB568.7070305@gmx.at> 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> From: Richard Copley Date: Sat, 1 Oct 2016 15:54:00 +0100 Message-ID: Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: martin rudalics Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 01 14:51:06 2016 Received: (at 24500) by debbugs.gnu.org; 1 Oct 2016 18:51:06 +0000 Received: from localhost ([127.0.0.1]:41345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqPNI-0002AU-Mc for submit@debbugs.gnu.org; Sat, 01 Oct 2016 14:51:06 -0400 Received: from mout.gmx.net ([212.227.15.18]:49383) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqPNF-00029z-9y for 24500@debbugs.gnu.org; Sat, 01 Oct 2016 14:51:01 -0400 Received: from [192.168.1.100] ([212.95.7.54]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lg1Tn-1b7EbF3mTD-00pdh9; Sat, 01 Oct 2016 20:50:55 +0200 Message-ID: <57F0058A.40806@gmx.at> Date: Sat, 01 Oct 2016 20:50:50 +0200 From: martin rudalics MIME-Version: 1.0 To: Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:xFA28Xb6P8S3uR/G90ciRN/fagS+tVm0FZF8CQ1QyAoB0YZvAjv mQeHea1Jfz2Mu1G4bNGvUG1V5Nt6tgUWAeYLbifFVmXakZ9CERYq+Zq7A70XdH8xCAqD7a9 mDa+cm2kMGFyt7bGAhRh2a9bQsyST1GX8TnZ0mg8fN24xU2dtuTkhSK4UlhBfzlvVsi/MgQ cZuMkeoAExcZFvW0gRjHA== X-UI-Out-Filterresults: notjunk:1;V01:K0:R4a4b5T8e+s=:5XSx/qYS0gUADRoOhSUtiF KOXq2v92V9PkdFiul7rNwpS05DprlFy6Algtr9Cuco29PqTMqMGnAc2Vw/Q7PFLnt6IMBYsCh VcHSlsIdzaUMbph+IFLijmH2pmW4fY8NinRW+cpMmBVDat/5JU509XJpdvLfccO78V02XUcXV NacsScQFgKJhPz2Z4PEGIypM77MOsTrnV1kZf2++wPUbO2CjkePVDkZYMznF8Az5XWkS4es1x STfk8maA3vGzLmPo7ipsKd9unKUTnUMaJYd5wXCNYTutWFfov6nJVBA8/xm5AjQtMEXssobhG 0J0nrg4Hb1VREjbWgED61/oa+qxST9ECrBszDKXkm7xy0W7Xw1mxmfowD8V3fMsxGPJHLPW8n Qdfk/ON7CFFr87DfAtaLhE/IGYul5edJTOA61w6XhkpY6qV0KstrRLBZsgurxxNVWx63WtQf9 OdF9ZF2fqi9hc5SkRWc0iZpMdZLSfeT7LeSNKeCxR/ronKG5VoymGrXIuSnCoHQx6AKJ50Hsd OsDHwagsftG2JMqA/nFQOhOq/ggspCNeqtvZHPUHvVTAynK1wyPl1PSo2DZAWUGpLkacpwYSm fQZWLtCQ4WXzIXaFlRmyiCfhs15Oztr2kAjK8xH7IUu+6jJAMAWE0c52EFXgphCG59eSIXtTr hpn2fsKYEb0jRLA+ZiUjLy1tpDHDhYHqwHkzuxmWO6iedU8ZP3ImB4JQaxDJ/N8CFvPnV/oSl XZu3w8Bom4bQO/4EEmBR65Ex3vp1hj1oON+q/obJCrdgdsrCwBxob6BHZUgoH/EDMgQ0yxyMy sJ1e3hRNLkRZUvILsyt7Jtn8PVq+A== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) >> 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? >> 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. > 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? >> 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. > 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 ... martin From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 03 14:33:08 2016 Received: (at 24500) by debbugs.gnu.org; 3 Oct 2016 18:33:08 +0000 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 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 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) MIME-Version: 1.0 Received: by 10.159.40.1 with HTTP; Mon, 3 Oct 2016 11:32:31 -0700 (PDT) In-Reply-To: <57F0058A.40806@gmx.at> 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> From: Richard Copley Date: Mon, 3 Oct 2016 19:32:31 +0100 Message-ID: Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: martin rudalics Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 03 15:36:16 2016 Received: (at 24500) by debbugs.gnu.org; 3 Oct 2016 19:36:16 +0000 Received: from localhost ([127.0.0.1]:43340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1br928-0006Z0-0F for submit@debbugs.gnu.org; Mon, 03 Oct 2016 15:36:16 -0400 Received: from mail-ua0-f173.google.com ([209.85.217.173]:36679) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1br926-0006Yk-0t for 24500@debbugs.gnu.org; Mon, 03 Oct 2016 15:36:14 -0400 Received: by mail-ua0-f173.google.com with SMTP id n13so159723510uaa.3 for <24500@debbugs.gnu.org>; Mon, 03 Oct 2016 12:36:13 -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:content-transfer-encoding; bh=cjg+M6HwOVOXaW4ZUpMirn7kxciYVDV+ZTgTlr/K+ww=; b=Eiti1iayL2dDWN4pqjikRsJu7VEjO6u1wn4XhCiA3HgIv3rz2c3aElaxH/8reigWSo K7m3AolIBSYoByPY06bkazVCfqVPPdPvpSHQAtnJsrkyfpUpZ6HeXSDeCncXt1O4UhKY eAa/mxfqv9y6XMIYswxDZHpgflSJ+n6zQpgQlH8c9fB0FOOA5iYs1FNl6VtPcwRIYPIj u7km35mcDyTAZisRFQ+zEKJHW9+XHnm8Zh2pN1Sdk7Hs9ovNqcdl7amlbx7n2tal1At4 Arqb/rtTlpGySXYhG7woZad7rhrgLCHXMjgk2CXN84094zSTFWdkrwsspHLge2rkrs03 35mQ== 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:content-transfer-encoding; bh=cjg+M6HwOVOXaW4ZUpMirn7kxciYVDV+ZTgTlr/K+ww=; b=FDsDXTd18fPutQr/S7mCqing7ms/qpJz7bv3NheGZmvNNJKtB7T+2yo7iam2HOLVOT e5N3zYd0iDuPh/n8/GNOe+/+tUulcUKM5Ah7wgmJOAKys7LjO7zOH4KkJeh2CwIAqo1Q tG11UJYK3haufaHXYoW9pKPHUtHAkbNHUbJyBWwazUx0udL43fh3NyJM6yTqCr7HoNr6 Oc58AdPsewwq8MwkEhoZCDFJBZFR4+jilOpu+zUGF79C5Vx95LB2GbRGqYk4wEnn6irz SHFuo4kHTW2jQqhR5227Pyjx/RBQGlqeqALD+bdILW/rlPIozlboNxHIJOlLpARW/l8n PwXQ== X-Gm-Message-State: AA6/9RmAbeMSzVI+Mb42K5AHzoGeYDwidjZeMFHd6URe68kHkUNoeiIVEg8y1XuMzIJMv7iQoIPV80PxAiXF5g== X-Received: by 10.159.32.101 with SMTP id 92mr12547785uam.123.1475523368553; Mon, 03 Oct 2016 12:36:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.1 with HTTP; Mon, 3 Oct 2016 12:35:38 -0700 (PDT) In-Reply-To: References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> From: Richard Copley Date: Mon, 3 Oct 2016 20:35:38 +0100 Message-ID: Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: martin rudalics Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 29 September 2016 at 00:21, Richard Copley wrote: > On 24 September 2016 at 20:04, martin rudalics wrote: >> I attached two patches that seem to work, but without any warranty (I do >> not fully understand the intentions of frame-focus/focus_frame and >> x_get_focus_frame yet). The purpose of these patches is to keep the >> =E2=80=98next-window=E2=80=99 and =E2=80=98other-window=E2=80=99 mechani= sms symmetric whenever a frame >> shares its minibuffer with other frames: >> >> (1) The frame.c patch changes the behavior of =E2=80=98do_switch_frame= =E2=80=99 by >> redirecting focus to another frame that shares this frame's minibuffer >> even when that other frame has no pending minibuffer activity. >> >> (2) The window.c patch simply inhibits =E2=80=98next-window=E2=80=99 to = select a window >> on a frame that has no pending minibuffer activity. >> >> Please try these patches (only one at a time because the window.c patch >> makes the frame.c patch moot) and tell me whether they have any bad >> effects. >> >> Thanks, martin > > Thank you! > [...] > > I'll try patch (2) later. It sounds logical to me. I've been using the window.c patch for a few days and I haven't noticed any badness. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 04 02:49:46 2016 Received: (at 24500) by debbugs.gnu.org; 4 Oct 2016 06:49:46 +0000 Received: from localhost ([127.0.0.1]:43672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brJXt-0000Zg-Qq for submit@debbugs.gnu.org; Tue, 04 Oct 2016 02:49:45 -0400 Received: from mout.gmx.net ([212.227.15.15]:59784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brJXs-0000ZN-A9 for 24500@debbugs.gnu.org; Tue, 04 Oct 2016 02:49:44 -0400 Received: from [192.168.1.100] ([212.95.7.6]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LwJRe-1aqAcZ1tsM-01804F; Tue, 04 Oct 2016 08:49:37 +0200 Message-ID: <57F350F9.5080704@gmx.at> Date: Tue, 04 Oct 2016 08:49:29 +0200 From: martin rudalics MIME-Version: 1.0 To: Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:spKj5pMHLWAhC6c3U5eS8u+vloSLurU31k/hJGZFLWdDmA8HIEm 7xWNfwkXTMuA+NITgdy3ZLVsg7i2ciyBGFgGrl/7npKbOUdqegyp+/fBCy5nwJwUEqOQFEX lRWUyBhW2557tDPzyfIrgFnBdNMRBzMwaAX1+LDypVvVUsSwXe1g7ZG7dgQZP33aSu2YTRA Tm0oxGACQxUTeJZLQBXNw== X-UI-Out-Filterresults: notjunk:1;V01:K0:KAPzosn1IAo=:zaLSo8q4hINseU2BDiiIIj frCHOlKVHuVFzMcix2kSlRVVjZU3avQH8RmHmtF7IJNVRetVZXrujJvRfyfd2rx4Nx9zFtSvB ZHm767f2USaMt9lAx3z/LV6IcT97qr10Aq+dY8XIQiijioU+hR+5OYSgLwOtmP+aHYvvJ7PIC aSLTKYHTyzgCKfB07IhJ6sA3oLj/ZRqv/2lzFHUyR0S8svaxxkos9+dmSOe/XH7IQ69GPcT+J Dfl1LsSk2EJN2Oji+5aKuOCrKa+caJg7gzTZHHf8RcKcWOB4rgETVlOutSE/B9C1Krcl4w6oc nsWiTlpI2Qnb4O6yHr+62TyAZ7DkIiEyM9GMWCzqH4B7jFyOsdBxfjWXw037+IRQc/cKnhITD ebmXq92ZZsNjAsNX4QYCYiG7EvJMRi8JgHoe2xCOpG76YfSdYWEFqVNM8SN2Nexxl5GGgTdWR 6pwm390wk+BRZ5Mw+NlULkIOVm3yp3BcfAzIdzM2YHaaJZLqC5SsbJDxs3+XS1RuVwyD0jVBA kXuoWhgn6Va6Qpb6bE7rGDNN69iIqyCfYrCybw/BA3akdfGaFZllOBSOKaASPztWC5Kn6/otZ ub49cWHxcmiuR1MHkmIQpLaGkdGIcfrvxPA/Mj0pjnaF2uDT035sKmE6I2Sm1r4EkPtp8DtTQ lKxzm9dS05JgWlmAsiPyPJit39cdFMWd2bc9ZOZeXbmApH3EnqHFmFxmoHKRgnJeWybJNC9/d gWOjKXpFyiggGa3NQfCqqoZclUnaY9+Q8xfNLjv1CG4pyZbyBF2E0HDzm84qyRw1kzusaPbPS /5LvJvgFXz0xB2r1lf4dP53qK0Bag== X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > 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? No. I can't reproduce that. It seems to make the previous frame sort of a modal window - something I experience with Emacs only when asking a ‘yes-or-no-p’ question. [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.15.15 listed in wl.mailspike.net] 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.6 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > 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? No. I can't reproduce that. It seems to make the previous frame sort of a modal window - something I experience with Emacs only when asking a ‘yes-or-no-p’ question. [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.15.15 listed in wl.mailspike.net] 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.6 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > 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 in= serted: > do you see the same thing there as well? No. I can't reproduce that. It seems to make the previous frame sort of a modal window - something I experience with Emacs only when asking a =E2=80=98yes-or-no-p=E2=80=99 question. >> 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. So we can consider my patch to frame.c the culprit for the misbehavior you observe. Or at least the "greater freedom" it provides. > 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 dif= ference > after all (?) then it's not worth thinking about. It's possible that some of my settings or tools affect this. That's why it would have been interesting to hear a few more comments ... martin From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 04 02:49:48 2016 Received: (at 24500) by debbugs.gnu.org; 4 Oct 2016 06:49:48 +0000 Received: from localhost ([127.0.0.1]:43675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brJXw-0000Zv-0p for submit@debbugs.gnu.org; Tue, 04 Oct 2016 02:49:48 -0400 Received: from mout.gmx.net ([212.227.15.15]:62785) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brJXv-0000ZS-3A for 24500@debbugs.gnu.org; Tue, 04 Oct 2016 02:49:47 -0400 Received: from [192.168.1.100] ([212.95.7.6]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M7pku-1awAcf03yy-00vMsg; Tue, 04 Oct 2016 08:49:41 +0200 Message-ID: <57F350FC.4000800@gmx.at> Date: Tue, 04 Oct 2016 08:49:32 +0200 From: martin rudalics MIME-Version: 1.0 To: Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:UWFgLQHiH/SfuyUvzLV5liXpAr/pPuXTrQdIuzO0ma7rjKC/PtH XlFCURdykZSyh+bKTJ4P/kOcs2YtFDbF/JLH7uF1Jo3MYts13KigATBu3AE+h5CuLpTo8ej urGnMLNjrUxalhu7k2RRIurgtQn0a8I90o/0836l4Z0BzD4aTd1MvXUJfq0qW9G14D3kKQm vFkGqYNOjlXn9sHq7fgvw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Td2tF4+O7AA=:RyB6N6GFUtn6i8IOEPruHe W9ZRpn8BiSbNw0kMfJJgILn9Xog79uf44A7gzkWcY9S/hVwobOlAcTlcWREiAzFq4v6swOZOa s9nUmuVIglqS8SkOo4dX4CVaKL7G3ILTXjb0b+5OuN6wDCf9Qfq6nyHgze+3o/NSkVc+43kow u3BViSpnKhyReKeBNKG6uudsECVJdl6RTVCIbELuvqncV4JKMQRf8XpragvN/oGvbbTmJveJo PgjMjRQGMygJ+eDH28/zqhO2bR6N4KOTvp5jtT7SSCCw09OwOzCmCElw1YHiCwCzaUQIpL+0N j2YtvnMeHIQU6OPIWqvAfRuRrnqnxm1dXLrJD630SyiRdkOOzDloMjvK+qn/TalRn/20n2ReI iWvM60hfpFl6C6HtnYqCNAkWUcYzCwj9JKKUnDEZ+BbX8cOil0QMdmec/j3ej6R+6qyYO0gpl VleTWb9fAG27WSx9vhMTuQ2sfjy/LgZ75mhAr/36BU1qH/pOyNP7FKIoVQwmzBpCeRuWmRxzJ TayftdyLAKW2vBeBoWlprDZbGygQyY5iKZIbd4lgpVkfH/rIXQb4XRe8yrIEDW57v6IoOfjTz vSJvnB4BCVjuuBDBF/c2NdjfXVLLnigZeHDwsQsUUizyXjcIFjD4LO1y4seIaf+ph4RsryBdu VhUaiJmO0vDk/Qe1KuzXRNFBlx/DC4rbsuH6GCHPMNA5mAsp+TWbI4ScbSiROHNVI1+i1JAHc nbMVTz+mtA0p+o59siyj9P8PDb94cxa1NTXKubYkEtNThkPPpdsVMstqcvv1QwLxecOElHZ9z 3tKdavVvjcBGXQ54jBVGJmK7WW5jA== X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > I've been using the window.c patch for a few days and I haven't noticed > any badness. If no one objects I'll check it into master by the end of the week. Thanks for testing, martin [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.15.15 listed in wl.mailspike.net] 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.6 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > I've been using the window.c patch for a few days and I haven't noticed > any badness. If no one objects I'll check it into master by the end of the week. Thanks for testing, martin [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.15.15 listed in wl.mailspike.net] 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.6 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > I've been using the window.c patch for a few days and I haven't noticed > any badness. If no one objects I'll check it into master by the end of the week. Thanks for testing, martin From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 08 13:37:58 2016 Received: (at 24500) by debbugs.gnu.org; 8 Oct 2016 17:37:59 +0000 Received: from localhost ([127.0.0.1]:48945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsvZO-0000Ex-OM for submit@debbugs.gnu.org; Sat, 08 Oct 2016 13:37:58 -0400 Received: from mout.gmx.net ([212.227.17.20]:57362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsvZM-0000Ek-Td for 24500@debbugs.gnu.org; Sat, 08 Oct 2016 13:37:57 -0400 Received: from [192.168.1.100] ([212.95.7.17]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MfjJY-1bY6tl1A0q-00NCnC; Sat, 08 Oct 2016 19:37:49 +0200 Message-ID: <57F92EE8.3030203@gmx.at> Date: Sat, 08 Oct 2016 19:37:44 +0200 From: martin rudalics MIME-Version: 1.0 To: Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WA7V7quhBWIS2bP1IS/NWsuyeK4//5VLrVbNcwW10mtx84O3FfS r3i1AxmeZ41cBk8Jx2y7mKbL/ozCyVsLl5OQREy61uDsGTaHjEoumQBEsOOkUMsl39Rf6P+ OFET4HeOTSGKI7YZSZL0Rpj0L2MLsGsBwnXRnULDLAYjqpOWcV6PU4xOKbay1swfVZkRZmh 6ck2xZJVe2x2H9VMiwGiQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:XukFtUbi4/s=:7kIuWPXgJqMoTINiHaBL9D 7n6BPAMuIb9XMJk0cC1xyX5C9afUK3AcsqjVKP2WLImxeJ0JJM6oYCb3xJDD0Gmg7i4aQArFp fXqyCWTVlueavkOt1BkLJMfH6k8houq1evJE8pR1y6OVRZhPIwnZRN75k4QhR7RZbhXutBkSo ptPoOOgCfZaKkCtNvtmZtSTH9rWoi1osIUK0bROeYJx6+DUSi/zwZFULzWkiSVpk9iu/uJIor +vidg2NGAyR9bOFMM4YpmT4bh9gOvpwO+iH86DqXn6VzF2nOkYKYjGV9JEEIMZRaoVvjE4LgG /8m8AD+ARIpvQM+1ywBRy7yT6xQcrrrsjS+CKjOkw3egIRY6DCc9aro1eed1VwEcPb7N8J34g xj0kxuhVgHpSqxq9kpJC8rggoZ2x+0We80kjgWNEQVmcRYthvlzRjXOaDMAesqud/XWlj6jXo L0EksmcUL7SOOHAF7+ZIyt+UTfldb/xlH4mkDanjlKHmdFbRqUDMvSDwmItqzkEtcM3AHqY6l a0Fm0zH0hxOai7NTmNXlN09ZfI+sC7cmJgmE9OHUHZsNgL85lrs/no/2o71dLNzIIm3OX+xdA tTBRDKpgINP5tbYov+09Vfz4LqWS9rk+jC7Dy8RqprwVlo82/UCb3DXerKL4kpe1L8jgLoz9G 9QNTyysxZjVpxd+mwXuZ4XENL9A+LTOX3Kx/z2ys0C1jM53OTTSR5A1fhDbRJmslLB1aSXkpe nd8rpzCfUbWU7GWNmUC9A/GjADw5LytjMs9Qly9A6qI3Kq6gd7/5PgzszvXQ2BPUNABcytDT6 dB3wClNqKNCzULN5fWAnyRIdaQgOg== X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > I've been using the window.c patch for a few days and I haven't noticed > any badness. I see the following problem with emacs -Q: Evaluate [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.20 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.17 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.17.20 listed in wl.mailspike.net] X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > I've been using the window.c patch for a few days and I haven't noticed > any badness. I see the following problem with emacs -Q: Evaluate [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.17 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.17.20 listed in wl.mailspike.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.20 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) > I've been using the window.c patch for a few days and I haven't noticed > any badness. I see the following problem with emacs -Q: Evaluate (make-frame '((minibuffer . nil))) In the minibuffer-less frame do M-x In the minibuffer type C-x 5 o In the minibuffer-less frame type C-x 5 o Now back in the minibuffer typing C-x o does nothing. You can only get out via C-x 5 o. The situation improves on the unpatched one because there is a way out of this loop and in particular one your typed before. Still this is only a 50% solution. When we do C-x o and we do not redirect focus as in the frame.c patch, frame focus sticks on the minibuffer. We should tell Windows to direct focus back to the minibuffer-less frame. I'll check this on GNU/Linux tomorrow. In any case, consider reconsidering. martin From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 08 14:29:10 2016 Received: (at 24500) by debbugs.gnu.org; 8 Oct 2016 18:29:10 +0000 Received: from localhost ([127.0.0.1]:48961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bswMw-0001VE-9v for submit@debbugs.gnu.org; Sat, 08 Oct 2016 14:29:10 -0400 Received: from mail-vk0-f54.google.com ([209.85.213.54]:35626) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bswMu-0001V0-7c for 24500@debbugs.gnu.org; Sat, 08 Oct 2016 14:29:08 -0400 Received: by mail-vk0-f54.google.com with SMTP id 192so67448047vkl.2 for <24500@debbugs.gnu.org>; Sat, 08 Oct 2016 11:29:08 -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=utXpLIKnZgnUhLhmRtB2G7fvg9ZD5YomMXmRdtZVYLw=; b=XjFBWBzkp/UWi8rF03h9y/M0lCFbAyHfqZMnbIGrDnbynqeMS2MACk5WICnKTs+nRg vMZYizHqn/4cdyQt8YV8Efy6QnKS26rQty5JXR8RVqdW4MT1bMHvSZ8iFwYbzgUZPLPY Gm/aTGgoy8qAiOIGDLnXOt4/JA/SGn5oonXj1b5QDO164kZB9464RvnI2rihIfaJ3Fd3 8IU43N5fNnh6IvB25fAmPQl9SHKRgPt8AFva0Yq+afl8Kqxr5jLKJvHiSL5L+kUR4JRu oIkF/dnqSf1WrUGhnPqwemrlsy1IiPYdjCc1/bo2mUR8DlK3e3sRz0HB6clUBDZTP/SP tWww== 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=utXpLIKnZgnUhLhmRtB2G7fvg9ZD5YomMXmRdtZVYLw=; b=lIAw0cZE8hNYOK5tKt0iEmX0PEFkSodxftG+Yz4nsHgfMn0Pa1Ur8pz/zM+HgAr1YU joZoB4Mq4NCJVxa9iTfV7pu06zkUrsq6VkOatqQkq9FwX9P9w2xhDBF9iF/itJuI5K77 swvlJ+RlzINGGxB+1SESNqrSUyeQPxLmzn+r9qps1pzc/J7I+b7DTT+q4AK1FqB+jkAE WGgp+KgSqwDBMYfl7uUFVBdvNGQiG2h+p0ZpzXQe6ttcIyWbX+8kjYHYx0PiXDqLwyEQ XlBaqsoYxeGlXlGxZBg0NaXhTWDs6tEquepsA2ipmbOLJVGhTj7WSdSWycBJghDmr9Cj UhFw== X-Gm-Message-State: AA6/9RmHwDyn3Xt6P6YJFUxfYMy9bxHNTqYT9p2e+Nl3uPdug7xI2qT6knO1iLEaVsLuRU0A/22xeBCTpG6uMQ== X-Received: by 10.31.174.134 with SMTP id x128mr19048431vke.73.1475951342767; Sat, 08 Oct 2016 11:29:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.1 with HTTP; Sat, 8 Oct 2016 11:28:31 -0700 (PDT) In-Reply-To: <57F92EE8.3030203@gmx.at> References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57F92EE8.3030203@gmx.at> From: Richard Copley Date: Sat, 8 Oct 2016 19:28:31 +0100 Message-ID: Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present To: martin rudalics Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) On 8 October 2016 at 18:37, martin rudalics wrote: >> I've been using the window.c patch for a few days and I haven't noticed >> any badness. > > I see the following problem with emacs -Q: > > Evaluate > > (make-frame '((minibuffer . nil))) > > In the minibuffer-less frame do M-x > > In the minibuffer type C-x 5 o > > In the minibuffer-less frame type C-x 5 o > > Now back in the minibuffer typing C-x o does nothing. You can only get > out via C-x 5 o. Confirmed, sorry I missed that. > The situation improves on the unpatched one because there is a way out > of this loop and in particular one your typed before. Still this is > only a 50% solution. When we do C-x o and we do not redirect focus as > in the frame.c patch, frame focus sticks on the minibuffer. We should > tell Windows to direct focus back to the minibuffer-less frame. I'll > check this on GNU/Linux tomorrow. In any case, consider reconsidering. I'm not sure what you mean. Reconsider what? Do you want me to test with both patches at once? > martin From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 09 03:51:25 2016 Received: (at 24500) by debbugs.gnu.org; 9 Oct 2016 07:51:25 +0000 Received: from localhost ([127.0.0.1]:49261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bt8tI-0007Nx-Tl for submit@debbugs.gnu.org; Sun, 09 Oct 2016 03:51:25 -0400 Received: from mout.gmx.net ([212.227.15.19]:56448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bt8tG-0007Nf-7w for 24500@debbugs.gnu.org; Sun, 09 Oct 2016 03:51:23 -0400 Received: from [192.168.1.100] ([212.95.7.50]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MfEZG-1bVPjd0d7C-00OnFM; Sun, 09 Oct 2016 09:51:15 +0200 Message-ID: <57F9F6ED.2050408@gmx.at> Date: Sun, 09 Oct 2016 09:51:09 +0200 From: martin rudalics MIME-Version: 1.0 To: Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57F92EE8.3030203@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:00UjnrCftr8Qmpsr0bMhTBvUTKOUj7Gupv4O/xDDwg7mCwkkBYU sUoFOXWuIsPP5VJEv5TBHkmekmypr3EBqplkN85pIL10zu/QGRftfnkC2wJt97XVdV+3UBN fPDWVvE1TzkYyDoac58/hN4RI0NGaHPWwxyCXa2h9jGByZWEgw0krOp4Orvcbnr4/HUBhjV 97wHPLadLEw0wl3ARVmDg== X-UI-Out-Filterresults: notjunk:1;V01:K0:CMFv3fR4MxY=:qhm9Av6FlxztRYJAuj6qrw uxen/U8RUIQqEu3ooN/Wpwr2nkNV+n35OtQ0UioNs8OxZb/wSyA+qvMrAWhoa3IVFBzgx4Toa YseZE/2D+AQXjjCokmHQx2NTmVtQpwHqobupM2rNcYXo0wfqhwvzuVsU6Ld+xDV0vg0z/dO2E rFviB2tzPWWFUPedJ8wRyT5cxHuNra6rQJyzYt5+0UfoVLAyA/kUA2/nvlCUbd7PSBysdOlNO YxSsYdmh3Df35IRIByXXRawjL6TE3oafS/D0Eo7VsEVSf0Y/866qzxn93ehvZOZWTGGX+gBof iYkra4azU+IC4IcXCutsC/sicGtBOnanOh1gRc7XLOfTVqwmP3NG/MOJZ5p+7PrGM3d2QRPX4 ntHgkZXfsxi2REMkSqWBNfxNCX6RSPqWI1/Th3KQn2vNi1K5isaNLtwHAut/StyE9EymwSGG6 hMO8LtWvVxGKr7SfDpQDU3ndnyEeTdumujmJdOoa9XHuCvV8aC3fgzY2fYBF/8F0skx6Wkfpn M6+ZursqsGkCunMb6dhQRONxgzpiQfqu1GhgKNqz7nT/NcXHR+jbP67LtoYCbGKkH0H2GuNau 3keOVqCaMGtZX2lVtwBy0UY3iwrFFxH0LVDhc5NaxclRoz0FNLPTg9ch7KDAyfq8JmEoiitaP Zf///+a3Dw3fqJ+hKEKcPDyCjc0SeoizZyt1lMVjwKQgh4ZQkjmfMRAWvzETbiA1/cUZ4A9lE XWxanxja0rPiPK3t/h18MuGRV74RUjOJGFA/jjY3VSz9BeIUTAjShMZCXkvRZbl99uyfFlt1J SLxIknIHNPN+xJIanbhyX5aHxbkgw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 24500 Cc: Eli Zaretskii , 24500@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) > I'm not sure what you mean. Reconsider what? Reconsider what you consider the least evil ;-) > Do you want me to test > with both patches at once? This might be a good idea. After all, I couldn't find any real mishaps with my frame.c patch here. BTW I'm currently loading the following file with emacs -Q to test this: (defvar old (selected-frame)) (defvar new (make-frame '((minibuffer . nil)))) (defvar test (get-buffer-create "*test*")) (set-frame-width new 1640 nil t) (set-frame-width old 400 nil t) (set-frame-height old 200 nil t) (set-frame-position new 0 0) (set-frame-position old -1 -40) (set-window-buffer (frame-root-window new) test) (defun foo () (with-current-buffer test (goto-char (point-max)) (insert (format "%s - sw: %s - wfsw: %s - sf: %s - fff: %s - mbsw: %s\n" this-command (selected-window) (window-frame) (selected-frame) (frame-focus new) (minibuffer-selected-window))))) (add-hook 'post-command-hook 'foo) You will see that without the frame.c patch, C-x o will eventually insert those =E2=80=98handle-switch-frame=E2=80=99 events that redirect f= ocus to the frame where the command was issued. martin From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 17 04:58:19 2016 Received: (at 24500-done) by debbugs.gnu.org; 17 Oct 2016 08:58:19 +0000 Received: from localhost ([127.0.0.1]:36038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bw3kR-0000kj-BB for submit@debbugs.gnu.org; Mon, 17 Oct 2016 04:58:19 -0400 Received: from mout.gmx.net ([212.227.15.15]:51932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bw3kP-0000kS-6k for 24500-done@debbugs.gnu.org; Mon, 17 Oct 2016 04:58:17 -0400 Received: from [192.168.1.100] ([212.95.7.75]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MOOdZ-1bzced3auD-005sw8; Mon, 17 Oct 2016 10:58:10 +0200 Message-ID: <5804929B.2010107@gmx.at> Date: Mon, 17 Oct 2016 10:58:03 +0200 From: martin rudalics MIME-Version: 1.0 To: Richard Copley Subject: Re: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> <57F92EE8.3030203@gmx.at> <57F9F6ED.2050408@gmx.at> In-Reply-To: <57F9F6ED.2050408@gmx.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:3jcQxhdv2e+ZYobVeCnjq8q2HjN2JDnjFGOls67MyAX3SY09J5U uu1NFlSKaZ5gCviwG/PypAfL+IjuWQv+W9TvdNVyRsIgrDzQuJmEdA+hkvEil7ZsK9/Qe1a pnu2vyKbEMu5uNbd1TgihYWMBIG7hpVJnhU7gx4oHQYkVDMWqu1Q8Yjq5fJ7KwNLDLHLbNM N2C90uytSUXi+RRdjlyNQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:2A3hz218yEQ=:/cHOluVO5Re0+9KoN00uPi zYcxZ0Ghigqa/VkS4uPmIM3cx9yA4sRTza8dF3WSi3c3S5XmH4R/GpRguFlKpDD/ScI4E8ZdR t41pmXTb/m+nYp6NEZyaEuK3e0b4Me4GS6c1eFQxVv4owFbE8ed7n23Q9orWgNtwAEjCojyGu Rsqa9ZNAD+Cj5wRAqyK4DmIG3vPLBWMymBLEIhd11DSmxlgjiuIQjMWom6ghGrkIcAi4lXQom E1fUoKaWptqqobjHmtGv6hi8ID3eZqQsuypY9OClhx+C4pOluqH0IzvN2vbpyAeFIAsfmTxAf Um2DOCeRKsfcorjhfOpRzHD7DyM6ygytOFgdKZJpGcNx23v1VJzSlfIEi8hz+HGXPbDRDC8U3 SHA9SPdq/8DwunnY1b9bOXkNU9pzoWXrX9d6LPOq6IbHVbRMaioMyPmUQvV+WMUHHEjNDsYOj V+7blW7R6oRWJXiFA/CiVHy9FtI3aSRqNVkx4pLoa3t1lq7CO02aTwIwC3fYR09aaWEP5+8xe gNmRoT6GtnTZbpIQXErNQ0vAMZw3qW1AeTqPsa/UxDLzJ9nIYV1rZ08GydmkLUCvOnUb/0m8B N8JUFE/ZZ1L83Qz9F2S2xq8v82q3rGOaTLzkSHnG20jfbvXTW4l+MjNWKEP4KZ620IZi4nniB Ie05vuKXoiLRroJqBPYDWYwLKxeY3ThBY+CG3OXH/TInsityVS3hGGCxBockg0cqg7CMv7vIH vOFJ81PRNhvgEwKO03fTdlMzZoEPuCnGOiGRjGsecWA1EobpUeHrpz2zBMjJ3osgndriKqO4Z 1hTi9JGq+O6vty2erP4XN5RhvqQ8w== X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > > Do you want me to test > > with both patches at once? > > This might be a good idea. After all, I couldn't find any real mishaps > with my frame.c patch here. I installed both patches now on master. Bug closed. [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.75 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.15.15 listed in wl.mailspike.net] X-Debbugs-Envelope-To: 24500-done Cc: 24500-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.8 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > > Do you want me to test > > with both patches at once? > > This might be a good idea. After all, I couldn't find any real mishaps > with my frame.c patch here. I installed both patches now on master. Bug closed. [...] Content analysis details: (2.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [212.227.15.15 listed in wl.mailspike.net] 3.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [212.95.7.75 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.15 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (rudalics[at]gmx.at) -0.0 SPF_PASS SPF: sender matches SPF record > > Do you want me to test > > with both patches at once? > > This might be a good idea. After all, I couldn't find any real mishaps > with my frame.c patch here. I installed both patches now on master. Bug closed. Thanks, martin From unknown Thu Jun 19 14:05:39 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 14 Nov 2016 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator