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

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

[Richard Copley]

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))

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

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> 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?

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

[Richard Copley]

On 21 September 2016 at 18:47, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> 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?

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

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> 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.

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

[Tino Calancha]

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.

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 3104 bytes --]

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

[-- Attachment #2: other-window.diff --]
[-- Type: text/plain, Size: 1186 bytes --]

diff --git a/src/frame.c b/src/frame.c
index 00f25f7..b729249 100644
--- 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);
 	}
     }
diff --git a/src/window.c b/src/window.c
index 733cf75..428d572 100644
--- a/src/window.c
+++ b/src/window.c
@@ -2346,8 +2346,7 @@ candidate_window_p (Lisp_Object window, Lisp_Object owindow,
 	    == FRAME_TERMINAL (XFRAME (selected_frame)));
     }
   else if (WINDOWP (all_frames))
-    candidate_p = (EQ (FRAME_MINIBUF_WINDOW (f), all_frames)
-		   || EQ (XWINDOW (all_frames)->frame, w->frame)
+    candidate_p = (EQ (XWINDOW (all_frames)->frame, w->frame)
 		   || EQ (XWINDOW (all_frames)->frame, FRAME_FOCUS_FRAME (f)));
   else if (FRAMEP (all_frames))
     candidate_p = EQ (all_frames, w->frame);

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

[Richard Copley]

On 24 September 2016 at 20:04, martin rudalics <rudalics@gmx.at> 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
> ‘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

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.

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

[martin rudalics]

 > 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

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

[Richard Copley]

On 30 September 2016 at 09:32, martin rudalics <rudalics@gmx.at> 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

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

[Richard Copley]

On 30 September 2016 at 19:13, Richard Copley <rcopley@gmail.com> wrote:
> On 30 September 2016 at 09:32, martin rudalics <rudalics@gmx.at> 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

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

[martin rudalics]

 >> 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

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

[Richard Copley]

On 1 October 2016 at 09:44, martin rudalics <rudalics@gmx.at> 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.

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

[Richard Copley]

On 1 October 2016 at 11:30, Richard Copley <rcopley@gmail.com> wrote:
> On 1 October 2016 at 09:44, martin rudalics <rudalics@gmx.at> 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.

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

[martin rudalics]

 >> 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

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

[martin rudalics]

 > 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

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

[Richard Copley]

On 1 October 2016 at 14:08, martin rudalics <rudalics@gmx.at> 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

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

[martin rudalics]

 >> 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

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

[Richard Copley]

On 1 October 2016 at 19:50, martin rudalics <rudalics@gmx.at> 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

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

[Richard Copley]

On 29 September 2016 at 00:21, Richard Copley <rcopley@gmail.com> wrote:
> On 24 September 2016 at 20:04, martin rudalics <rudalics@gmx.at> 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
>> ‘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
>
> 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.

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

[martin rudalics]

 > 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.

 >> 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 difference
 > 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

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

[martin rudalics]

 > 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

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

[martin rudalics]

 > 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

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

[Richard Copley]

On 8 October 2016 at 18:37, martin rudalics <rudalics@gmx.at> 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

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

[martin rudalics]

 > 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 ‘handle-switch-frame’ events that redirect focus to the
frame where the command was issued.

martin

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

[martin rudalics]

 >  > 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