From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present Date: Thu, 29 Sep 2016 00:21:11 +0100 Message-ID: References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> <57E6CE51.1040600@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1475104941 16185 195.159.176.226 (28 Sep 2016 23:22:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Sep 2016 23:22:21 +0000 (UTC) Cc: 24500@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 29 01:22:17 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bpOB5-0003OI-0h for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Sep 2016 01:22:15 +0200 Original-Received: from localhost ([::1]:33754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpOB3-0004B0-2t for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Sep 2016 19:22:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpOAw-0003z3-3x for bug-gnu-emacs@gnu.org; Wed, 28 Sep 2016 19:22:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpOAr-0003oB-Ut for bug-gnu-emacs@gnu.org; Wed, 28 Sep 2016 19:22:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpOAr-0003o1-RB for bug-gnu-emacs@gnu.org; Wed, 28 Sep 2016 19:22:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bpOAr-0005jS-KJ for bug-gnu-emacs@gnu.org; Wed, 28 Sep 2016 19:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Sep 2016 23:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24500 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24500-submit@debbugs.gnu.org id=B24500.147510490922015 (code B ref 24500); Wed, 28 Sep 2016 23:22:01 +0000 Original-Received: (at 24500) by debbugs.gnu.org; 28 Sep 2016 23:21:49 +0000 Original-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 Original-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 Original-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) Original-Received: by 10.176.82.176 with HTTP; Wed, 28 Sep 2016 16:21:11 -0700 (PDT) In-Reply-To: <57E6CE51.1040600@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:123747 Archived-At: 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.