GNU bug report logs - #24500
25.1.50; Can't other-window from minibuffer if Ediff control panel frame present

Previous Next

Full log

Message #20 received at 24500 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Richard Copley <rcopley <at> gmail.com>
Cc: 24500 <at> debbugs.gnu.org
Subject: Re: 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 part 1 (text/plain, inline)]

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
‘next-window’ and ‘other-window’ mechanisms symmetric whenever a frame
shares its minibuffer with other frames:

(1) The frame.c patch changes the behavior of ‘do_switch_frame’ 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 ‘next-window’ 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

[other-window.diff (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.