From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#24500: 25.1.50; Can't other-window from minibuffer if Ediff control panel frame present Date: Sat, 24 Sep 2016 21:04:49 +0200 Message-ID: <57E6CE51.1040600@gmx.at> References: <83a8f1f8l0.fsf@gnu.org> <83mvj0dkhd.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080505060609040202070303" X-Trace: blaine.gmane.org 1474744023 694 195.159.176.226 (24 Sep 2016 19:07:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Sep 2016 19:07:03 +0000 (UTC) Cc: 24500@debbugs.gnu.org To: Eli Zaretskii , Richard Copley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 24 21:06:59 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 1bnsHb-0006DF-3c for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Sep 2016 21:06:43 +0200 Original-Received: from localhost ([::1]:35251 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnsHZ-00019m-J4 for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Sep 2016 15:06:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnsGz-0000iJ-Oc for bug-gnu-emacs@gnu.org; Sat, 24 Sep 2016 15:06:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bnsGw-0005gq-6h for bug-gnu-emacs@gnu.org; Sat, 24 Sep 2016 15:06:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnsGw-0005gm-39 for bug-gnu-emacs@gnu.org; Sat, 24 Sep 2016 15:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bnsGv-0000DF-OW for bug-gnu-emacs@gnu.org; Sat, 24 Sep 2016 15:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Sep 2016 19:06: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.1474743904744 (code B ref 24500); Sat, 24 Sep 2016 19:06:01 +0000 Original-Received: (at 24500) by debbugs.gnu.org; 24 Sep 2016 19:05:04 +0000 Original-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 Original-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 Original-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 In-Reply-To: <83mvj0dkhd.fsf@gnu.org> 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/iFWcOx1 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:123657 Archived-At: 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--