bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

With detached minibuf, query-replace doesn't work because
query-replace-read-args doesn't shift focus to minibuf for the replacement
string. Possibly related to Bug 64152. This worked in 28.1.

To reproduce, create init.el with these two lines:

(add-to-list 'initial-frame-alist '(minibuffer . nil))
(add-to-list 'minibuffer-frame-alist '(minibuffer . only))

Now run emacs:
emacs-29.1 -Q --load init.el

Run query-replace, usually bound to M-%. Focus will shift to the minibuf.
Enter a string and hit <return>. The minibuf will now prompt for a
replacement string, but focus will now be in the scratch buffer instead of
the minibuf, and it will be impossible to enter the replacement string
without re-focusing.


In GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, cairo version 1.17.6)
 of 2023-01-15 built on motul
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Arch Linux

Configured using:
 'configure --disable-silent-rules --prefix=/usr/local --sysconfdir=/etc
 --libexecdir=/usr/local/lib --localstatedir=/var
 --mandir=/usr/local/man --with-x --with-x-toolkit=gtk3
 --without-toolkit-scroll-bars --without-xaw3d --with-cairo
 --without-imagemagick --without-sound --without-gif
 --without-libsystemd --without-dbus --without-gconf --without-gsettings
 --without-selinux CFLAGS=-Os'

Configured features:
ACL CAIRO FREETYPE GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2 LIBOTF
LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP THREADS
TIFF X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: ELisp/d

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/rees/lib/lisp/cmuscheme hides /usr/local/share/emacs/28.1/lisp/cmuscheme
/home/rees/lib/lisp/tempo hides /usr/local/share/emacs/28.1/lisp/tempo
/home/rees/lib/lisp/rng-nxml hides /usr/local/share/emacs/28.1/lisp/nxml/rng-nxml
/home/rees/lib/lisp/syntax hides /usr/local/share/emacs/28.1/lisp/emacs-lisp/syntax

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core eieio-loaddefs
password-cache json map text-property-search mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date
subr-x tabify imenu man ansi-color pp seq byte-opt bytecomp byte-compile
cconv zoom-frm frame-cmds cl-macs gv frame-fns avoid server ps-ccrypt
html-mode dtrt-indent advice easy-mmode whitespace plain-mode edmacro
kmacro cl-loaddefs cl-lib fit-frame iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer 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 composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads inotify lcms2 dynamic-setting
font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 74590 6483)
 (symbols 48 8146 1)
 (strings 32 22376 2052)
 (string-bytes 1 771015)
 (vectors 16 15645)
 (vector-slots 8 222601 10111)
 (floats 8 64 30)
 (intervals 56 254 244)
 (buffers 992 13))

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Eli Zaretskii]

> Date: Sun, 6 Aug 2023 11:18:34 -0600
> From:  Jim Rees via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> With detached minibuf, query-replace doesn't work because
> query-replace-read-args doesn't shift focus to minibuf for the replacement
> string. Possibly related to Bug 64152. This worked in 28.1.
> 
> To reproduce, create init.el with these two lines:
> 
> (add-to-list 'initial-frame-alist '(minibuffer . nil))
> (add-to-list 'minibuffer-frame-alist '(minibuffer . only))
> 
> Now run emacs:
> emacs-29.1 -Q --load init.el
> 
> Run query-replace, usually bound to M-%. Focus will shift to the minibuf.
> Enter a string and hit <return>. The minibuf will now prompt for a
> replacement string, but focus will now be in the scratch buffer instead of
> the minibuf, and it will be impossible to enter the replacement string
> without re-focusing.

What I see here is that the frame where *scratch* is shown becomes the
selected frame, but input focus stays in the minibuffer frame, so if I
type the replacement string (without any refocusing), the command
accepts the replacement and starts replacing after I type RET.

YMMV, depending on your WM, I think.

> In GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, cairo version 1.17.6)
>  of 2023-01-15 built on motul

The Subject says "Emacs 29.1", but this report is from Emacs 28.1.  So
which one is the version where you see the problem?

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

The problem is in 29.1. I think report-emacs-bug just appends the info for
whatever version of emacs you are running at the time you report a bug.

I have tried two different window managers, twm and openbox, and get the bug
in both of them. However, it only happens if I am running with focus follows
mouse. It does not happen if I have set click to focus. The settings of
focus-follows-mouse and minibuffer-follows-selected-frame make no
difference.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Eli Zaretskii]

> Date: Fri, 12 Jan 2024 00:26:10 -0600
> From: Jim Rees <jim@rees.org>
> Cc: 65116@debbugs.gnu.org
> 
> The problem is in 29.1. I think report-emacs-bug just appends the info for
> whatever version of emacs you are running at the time you report a bug.

So Emacs 28 behaves correctly on your system in this scenario?

> I have tried two different window managers, twm and openbox, and get the bug
> in both of them. However, it only happens if I am running with focus follows
> mouse. It does not happen if I have set click to focus. The settings of
> focus-follows-mouse and minibuffer-follows-selected-frame make no
> difference.

Alan and Juri, could you please look into this issue?

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

28.1 works correctly. I am unable to test 28.2 right now but it had a
different problem. I think I was unable to enter the 'from' arg. If it's
important I can re-install 28.2 and test it.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello, Eli.

On Fri, Jan 12, 2024 at 14:00:29 +0200, Eli Zaretskii wrote:
> > Date: Fri, 12 Jan 2024 00:26:10 -0600
> > From: Jim Rees <jim@rees.org>
> > Cc: 65116@debbugs.gnu.org

> > The problem is in 29.1. I think report-emacs-bug just appends the info for
> > whatever version of emacs you are running at the time you report a bug.

> So Emacs 28 behaves correctly on your system in this scenario?

> > I have tried two different window managers, twm and openbox, and get the bug
> > in both of them. However, it only happens if I am running with focus follows
> > mouse. It does not happen if I have set click to focus. The settings of
> > focus-follows-mouse and minibuffer-follows-selected-frame make no
> > difference.

> Alan and Juri, could you please look into this issue?

I'm looking into it now.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello, Jim.

On Sun, Aug 06, 2023 at 11:18:34 -0600, Jim Rees wrote:

> With detached minibuf, query-replace doesn't work because
> query-replace-read-args doesn't shift focus to minibuf for the replacement
> string. Possibly related to Bug 64152. This worked in 28.1.

> To reproduce, create init.el with these two lines:

> (add-to-list 'initial-frame-alist '(minibuffer . nil))
> (add-to-list 'minibuffer-frame-alist '(minibuffer . only))

> Now run emacs:
> emacs-29.1 -Q --load init.el

> Run query-replace, usually bound to M-%. Focus will shift to the minibuf.
> Enter a string and hit <return>. The minibuf will now prompt for a
> replacement string, but focus will now be in the scratch buffer instead of
> the minibuf, and it will be impossible to enter the replacement string
> without re-focusing.


> In GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.36, cairo version 1.17.6)
>  of 2023-01-15 built on motul
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
> System Description: Arch Linux

.... and in a more recent post:

> The problem is in 29.1. I think report-emacs-bug just appends the info
> for whatever version of emacs you are running at the time you report a
> bug.

> I have tried two different window managers, twm and openbox, and get
> the bug in both of them. However, it only happens if I am running with
> focus follows mouse. It does not happen if I have set click to focus.
> The settings of focus-follows-mouse and
> minibuffer-follows-selected-frame make no difference.

I can't reproduce the bug on my setup, GNU/Linux with an XFCE window
manager with "focus follows mouse" set.  I've tried both with Emacs
29.1, and a fairly recent version from our git master branch.

Seeing as how "focus follows mouse" is set, does it make any difference
where on the screen the mouse is when you perform the various steps of
the bug recipe?  Where was your mouse when entering the original string
and then attempting to enter the replacement string?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Normally this happens when I'm trying to edit text in a buffer. I only
mention the scratch buffer in the bug report because that's the easiest way
to reproduce the problem.

The mouse starts out somewhere in the window displaying the text I'm trying
to edit. I type M-%, enter the 'from' text, and when I hit <enter> the mouse
warps to the upper right corner of the window. I get the 'to' prompt but
then I can't type anything because the focus is on the edit window, not on
the minibuf.

I don't think it matters where in the text window the mouse starts out, but
it's hard to tell. About 10% of the time M-% works correctly but I can't
figure out why. I'll try to see if it has something to do with mouse
position.

Can you try with twm? It is lightweight and should run with no
configuration. I'm at a loss as to why I'm seeing this bug and no one else
is.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello, Jim.

On Fri, Jan 12, 2024 at 09:59:10 -0600, Jim Rees wrote:
> Normally this happens when I'm trying to edit text in a buffer. I only
> mention the scratch buffer in the bug report because that's the easiest way
> to reproduce the problem.

> The mouse starts out somewhere in the window displaying the text I'm trying
> to edit. I type M-%, enter the 'from' text, and when I hit <enter> the mouse
> warps to the upper right corner of the window. I get the 'to' prompt but
> then I can't type anything because the focus is on the edit window, not on
> the minibuf.

> I don't think it matters where in the text window the mouse starts out, but
> it's hard to tell. About 10% of the time M-% works correctly but I can't
> figure out why. I'll try to see if it has something to do with mouse
> position.

> Can you try with twm? It is lightweight and should run with no
> configuration. I'm at a loss as to why I'm seeing this bug and no one else
> is.

I've installed twm which, as you say, is lightweight (~250 kB) but it
pulled in a ~750 kB font with it.  ;-)  No big deal (like it would have
been 30 years ago).

I can reproduce the bug with this set up.  With the mouse starting in
the text frame, the bug as you describe it happens, and the mouse must
be moved to the minibuffer frame to be able to type in the replacement
text.

If the mouse starts in the MB frame, typing M-% allows one to enter
original and replacement texts without moving the mouse, but this is
useless, since it then attempts to substitute in the mini-window.

I'll have a closer look at this to see if I can fix it.  But things with
detached minibuffers and focus are complicated and have given rise to
quite a few bugs over the years.  Add in focus follows mouse, and it
gets more complicated still.  ;-(

Reading between the lines, it would appear you're still on Emacs 28
because of this bug.  That's a pity, and it would be good to fix things.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Well that's a relief. I do have an unusual setup with detached minibuf and
focus follows mouse. There has been a lot of churn in replace.el and frame.c
lately and I keep hoping the bug will go away on its own. I don't really
understand all the focus changes in the code but I do see why they are
necessary.

I have a workaround, I have bound this to a key and use it to re-focus to
the minibuf so I can enter the 'to' text:

(select-frame-set-input-focus (window-frame (minibuffer-window)))

But that requires manual intervention so for now I'm sticking with 28.1.

(Focus follows mouse was common years ago, but with the relentless quest to
make X work just like MS Windows it has become less popular)

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello, Jim.

On Fri, Jan 12, 2024 at 12:57:42 -0600, Jim Rees wrote:
> Well that's a relief. I do have an unusual setup with detached minibuf and
> focus follows mouse. There has been a lot of churn in replace.el and frame.c
> lately and I keep hoping the bug will go away on its own. I don't really
> understand all the focus changes in the code but I do see why they are
> necessary.

> I have a workaround, I have bound this to a key and use it to re-focus to
> the minibuf so I can enter the 'to' text:

> (select-frame-set-input-focus (window-frame (minibuffer-window)))

> But that requires manual intervention so for now I'm sticking with 28.1.

I've been playing with the setup for an hour or two.  It seems that
performing some action in the minibuffer (say, M-x auto-revert-mode, but
anything will do) causes M-% to work properly.  But then, the moment the
mouse leaves the active frame or window (I'm not sure which), M-% no
longer works properly, until the next minibuffer action.

I know this isn't much help to you, but it should be a help to us,
tracking down what's going wrong.

> (Focus follows mouse was common years ago, but with the relentless quest to
> make X work just like MS Windows it has become less popular)

Yes.  I've never liked it, because it involves moving the hand
repeatedly between mouse and keyboard.  But I can understand it being
quite popular, even if some time in the past.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Eli Zaretskii]

> Date: Fri, 12 Jan 2024 21:44:11 +0000
> Cc: 65116@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Jim.
> 
> On Fri, Jan 12, 2024 at 12:57:42 -0600, Jim Rees wrote:
> > Well that's a relief. I do have an unusual setup with detached minibuf and
> > focus follows mouse. There has been a lot of churn in replace.el and frame.c
> > lately and I keep hoping the bug will go away on its own. I don't really
> > understand all the focus changes in the code but I do see why they are
> > necessary.
> 
> > I have a workaround, I have bound this to a key and use it to re-focus to
> > the minibuf so I can enter the 'to' text:
> 
> > (select-frame-set-input-focus (window-frame (minibuffer-window)))
> 
> > But that requires manual intervention so for now I'm sticking with 28.1.
> 
> I've been playing with the setup for an hour or two.  It seems that
> performing some action in the minibuffer (say, M-x auto-revert-mode, but
> anything will do) causes M-% to work properly.  But then, the moment the
> mouse leaves the active frame or window (I'm not sure which), M-% no
> longer works properly, until the next minibuffer action.
> 
> I know this isn't much help to you, but it should be a help to us,
> tracking down what's going wrong.

If this is WM-specific, maybe Po Lu (CC'ed) could help us understand
what happens here?  Perhaps some message we expect from X is not being
received in this scenario?

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello, Eli and Po.

On Sat, Jan 13, 2024 at 08:34:28 +0200, Eli Zaretskii wrote:
> > Date: Fri, 12 Jan 2024 21:44:11 +0000
> > Cc: 65116@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > On Fri, Jan 12, 2024 at 12:57:42 -0600, Jim Rees wrote:
> > > Well that's a relief. I do have an unusual setup with detached minibuf and
> > > focus follows mouse. There has been a lot of churn in replace.el and frame.c
> > > lately and I keep hoping the bug will go away on its own. I don't really
> > > understand all the focus changes in the code but I do see why they are
> > > necessary.

> > > I have a workaround, I have bound this to a key and use it to re-focus to
> > > the minibuf so I can enter the 'to' text:

> > > (select-frame-set-input-focus (window-frame (minibuffer-window)))

> > > But that requires manual intervention so for now I'm sticking with 28.1.

> > I've been playing with the setup for an hour or two.  It seems that
> > performing some action in the minibuffer (say, M-x auto-revert-mode, but
> > anything will do) causes M-% to work properly.  But then, the moment the
> > mouse leaves the active frame or window (I'm not sure which), M-% no
> > longer works properly, until the next minibuffer action.

> > I know this isn't much help to you, but it should be a help to us,
> > tracking down what's going wrong.

> If this is WM-specific, maybe Po Lu (CC'ed) could help us understand
> what happens here?  Perhaps some message we expect from X is not being
> received in this scenario?

I've got some more info which might be useful.  There are two calls to
read_minibuf (the lowest level of minibuffer access in src/minibuf.c)
during the query-replace processing.

during the first access, the focus gets redirected to the minibuffer at
L812 of minibuf.c, with

  if (!EQ (mini_frame, selected_frame))
      Fredirect_frame_focus (selected_frame, mini_frame);

..  [I don't know what undoes this focus redirection later.]  After the
recursive edit, provided it wasn't aborted with C-g, the code moves the
focus back to the main frame with, at L963,

    call2 (Qselect_frame_set_input_focus, calling_frame, Qnil);

..  In the bug scenario, if this statement at L963 is commented out, the
bug symptoms are no longer evident.

So it seems something in the second read_minibuf call is preventing the
Fredirect_frame_focus at L812 from working.

We can hardly avoid needing to use GDB, here.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello again, Eli and Po.

On Sat, Jan 13, 2024 at 09:23:26 +0000, Alan Mackenzie wrote:
> On Sat, Jan 13, 2024 at 08:34:28 +0200, Eli Zaretskii wrote:
> > > Date: Fri, 12 Jan 2024 21:44:11 +0000
> > > Cc: 65116@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, acm@muc.de
> > > From: Alan Mackenzie <acm@muc.de>

> > > On Fri, Jan 12, 2024 at 12:57:42 -0600, Jim Rees wrote:
> > > > Well that's a relief. I do have an unusual setup with detached minibuf and
> > > > focus follows mouse. There has been a lot of churn in replace.el and frame.c
> > > > lately and I keep hoping the bug will go away on its own. I don't really
> > > > understand all the focus changes in the code but I do see why they are
> > > > necessary.

> > > > I have a workaround, I have bound this to a key and use it to re-focus to
> > > > the minibuf so I can enter the 'to' text:

> > > > (select-frame-set-input-focus (window-frame (minibuffer-window)))

> > > > But that requires manual intervention so for now I'm sticking with 28.1.

> > > I've been playing with the setup for an hour or two.  It seems that
> > > performing some action in the minibuffer (say, M-x auto-revert-mode, but
> > > anything will do) causes M-% to work properly.  But then, the moment the
> > > mouse leaves the active frame or window (I'm not sure which), M-% no
> > > longer works properly, until the next minibuffer action.

> > > I know this isn't much help to you, but it should be a help to us,
> > > tracking down what's going wrong.

> > If this is WM-specific, maybe Po Lu (CC'ed) could help us understand
> > what happens here?  Perhaps some message we expect from X is not being
> > received in this scenario?

> I've got some more info which might be useful.  There are two calls to
> read_minibuf (the lowest level of minibuffer access in src/minibuf.c)
> during the query-replace processing.

> during the first access, the focus gets redirected to the minibuffer at
> L812 of minibuf.c, with

>   if (!EQ (mini_frame, selected_frame))
>       Fredirect_frame_focus (selected_frame, mini_frame);

> ..  [I don't know what undoes this focus redirection later.]  After the
> recursive edit, provided it wasn't aborted with C-g, the code moves the
> focus back to the main frame with, at L963,

>     call2 (Qselect_frame_set_input_focus, calling_frame, Qnil);

> ..  In the bug scenario, if this statement at L963 is commented out, the
> bug symptoms are no longer evident.

> So it seems something in the second read_minibuf call is preventing the
> Fredirect_frame_focus at L812 from working.

No, that is not the case.

> We can hardly avoid needing to use GDB, here.

I've done some GDBing, and what is happening in the bug case is that the
window manager, twm, is sending a focus-in event to Emacs when we start
trying to read characters.  This focus-in event switches the current
frame away from the minibuffer's frame to the main frame.

I don't know why this is happening, or why omitting the
select-frame-set-input-focus at the end of the first read_minibuf call
causes us to be spared this focus-in event on the second read_minibuf
call.

It is not clear whether the bug is in the Emacs master (with which I've
been testing) or twm.

Help from somebody more experienced with X-Windows would be welcome.

-- 
Alan Mackenzie (Nuremberg, Germany).


> -- 
> Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Could it have something to do with the mouse warping? Why is the mouse
warping at all? I would prefer it stay right where it is. I'm pretty sure it
did at some recent time in the past, maybe emacs 26.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello, Jim.

On Sat, Jan 13, 2024 at 11:00:50 -0600, Jim Rees wrote:
> Could it have something to do with the mouse warping? Why is the mouse
> warping at all? I would prefer it stay right where it is. I'm pretty
> sure it did at some recent time in the past, maybe emacs 26.

If so, what is causing the mouse to warp at all?  Emacs shifts the focus
from the main frame to the minibuffer frame, so presumably that causes a
mouse warp.  Or does it?

Something is remembering state.  Performing a minibuffer action sets this
state, namely to something which allows M-% to work.  Moving the mouse
out of the main frame changes this state to something where M-% no longer
works, even after moving it back into the frame.

Maybe the minibuffer action causes some variable to "remember" it's "in
the minibuffer", so it doesn't try later to shift the focus to the main
frame, whereas when the mouse has been moved out and in again, this
variable "remembers" it's "in the main frame".  Or something like that.

But the problem only occurs during the second minibuffer use in M-%, not
the first one.

Is this state store in Emacs, in twm, or in X-Windows?  I'm inclined to
suspect twm, since the bug only seems to occur with twm and one other
window manager.  But my previous paragraph implies there's some relevant
state stored in Emacs, too.

I wish I knew more about X-Windows and window managers.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Drew Adams]

> Could it have something to do with the mouse warping? Why is the mouse
> warping at all? I would prefer it stay right where it is. I'm pretty sure
> it did at some recent time in the past, maybe emacs 26.

...Yes, I hear a distant bell ringing...

(Stuck on Emacs 26...)

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello, Drew.

On Sat, Jan 13, 2024 at 19:15:33 +0000, Drew Adams wrote:
> > Could it have something to do with the mouse warping? Why is the mouse
> > warping at all? I would prefer it stay right where it is. I'm pretty sure
> > it did at some recent time in the past, maybe emacs 26.

> ...Yes, I hear a distant bell ringing...

> (Stuck on Emacs 26...)

Could you possibly try my patch for this bug on an Emacs more recent
than 26, and see if it helps at all with the things that have not been
right w.r.t. minibuffers and the like?

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Drew Adams]

> > > Could it have something to do with the mouse warping? Why is the mouse
> > > warping at all? I would prefer it stay right where it is. I'm pretty
> sure
> > > it did at some recent time in the past, maybe emacs 26.
> 
> > ...Yes, I hear a distant bell ringing...
> > (Stuck on Emacs 26...)
> 
> Could you possibly try my patch for this bug on an Emacs more recent
> than 26, and see if it helps at all with the things that have not been
> right w.r.t. minibuffers and the like?

No; sorry Alan, I can't.  I don't build Emacs,
I'm on MS Windows.  And too many things have
changed since Emacs 26.  I've given up trying
 to figure out focus problems etc.

Maybe someone at some point will report a
problem, giving a specific, operational recipe,
and maybe that'll get fixed, and maybe that
fix will help me with the problems I encounter.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello, Drew.

On Sat, Jan 13, 2024 at 21:19:36 +0000, Drew Adams wrote:
> > > > Could it have something to do with the mouse warping? Why is the mouse
> > > > warping at all? I would prefer it stay right where it is. I'm pretty
> > sure
> > > > it did at some recent time in the past, maybe emacs 26.

> > > ...Yes, I hear a distant bell ringing...
> > > (Stuck on Emacs 26...)

> > Could you possibly try my patch for this bug on an Emacs more recent
> > than 26, and see if it helps at all with the things that have not been
> > right w.r.t. minibuffers and the like?

> No; sorry Alan, I can't.  I don't build Emacs,
> I'm on MS Windows.  And too many things have
> changed since Emacs 26.  I've given up trying
>  to figure out focus problems etc.

I've not.

> Maybe someone at some point will report a
> problem, giving a specific, operational recipe,
> and maybe that'll get fixed, .....

That's precisely what's just happened, or will have happened if the OP's
testing shows the expected OK.

> ..... and maybe that fix will help me with the problems I encounter.

Maybe.  Who knows?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello again, Jim.

On Sat, Jan 13, 2024 at 11:00:50 -0600, Jim Rees wrote:
> Could it have something to do with the mouse warping? Why is the mouse
> warping at all? I would prefer it stay right where it is. I'm pretty sure it
> did at some recent time in the past, maybe emacs 26.

I think I've got it.  The problem was which frame has X-Windows's
focus.  Most of the time, that's the minibuffer's/echo-area's frame,
because at the end of most commands, something gets written to the
echo-area.

In the current bug situation, after the first read-minibuffer of M-%,
nothing is output to the echo-area, but the GUI focus is switched to the
main frame.  It stays there for the second read-minibuffer, and that's
what you saw on your terminal.

The solution would appear to be explicitly to switch the focus to the
minibuffer frame before attempting to read from it.  The following patch
does this, and appears to work for me.



diff --git a/src/minibuf.c b/src/minibuf.c
index f4f9da9c3f9..d940c0d717f 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -825,6 +825,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
   /* Use set_window_buffer instead of Fset_window_buffer (see
      discussion of bug#11984, bug#12025, bug#12026).  */
   set_window_buffer (minibuf_window, Fcurrent_buffer (), 0, 0);
+  /* Make sure the minibuffer's frame has the input focus.  This is
+     particularly for the twm window manager with detached minibuffer.
+     (See Bug#65116.)  */
+  if (!EQ (mini_frame, selected_frame))
+    call2 (Qselect_frame_set_input_focus, mini_frame, Qt);
   Fselect_window (minibuf_window, Qnil);
   XWINDOW (minibuf_window)->hscroll = 0;
   XWINDOW (minibuf_window)->suspend_auto_hscroll = 0;


Would you please apply the patch, rebuild your Emacs, and see if the
problem really is solved.  The patch should apply cleanly to either the
Emacs master, or the 29.x sources.  (I'm assuming you have no troubles
with patching and building, but if so, feel free to send me private
email.)  Then please confirm things are OK so that I can close the bug,
or tell me what's still not working properly.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Yes that fixed it. Thanks.

The focus logic did change some time around emacs 26 or 27. Before that time
the X focus stayed with the edit frame, but input was directed (by emacs I
guess) to the minibuf. Now the X focus shifts to the minibuf and back, which
is why my mouse warps to the upper corner of the edit frame. It's annoying
and I'll be looking for a fix, but I can't honestly say it's an emacs bug.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Eli Zaretskii]

> Date: Sat, 13 Jan 2024 17:53:17 -0600
> From: Jim Rees <jim@rees.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, Po Lu <luangruo@yahoo.com>,
> 	65116@debbugs.gnu.org
> 
> Yes that fixed it. Thanks.

Can you please revert that change, and instead test the patch below?
It was recently installed on the master branch of Emacs.

diff --git a/src/xterm.c b/src/xterm.c
index 77d6550..fe39817 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -13370,13 +13370,12 @@ xi_focus_handle_for_device (struct x_display_info *dpyinfo,
 	 frame's user time.  */
       x_display_set_last_user_time (dpyinfo, event->time,
 				    event->send_event, false);
-
       device->focus_frame = NULL;
 
       /* So, unfortunately, the X Input Extension is implemented such
-	 that means XI_Leave events will not have their focus field
-	 set if the core focus is transferred to another window after
-	 an entry event that pretends to (or really does) set the
+	 that XI_Leave events will not have their focus field set if
+	 the core focus is transferred to another window after an
+	 entry event that pretends to (or really does) set the
 	 implicit focus.  In addition, if the core focus is set, but
 	 the extension focus on the client pointer is not, all
 	 XI_Enter events will have their focus fields set, despite not
@@ -28805,6 +28804,33 @@ x_focus_frame (struct frame *f, bool noactivate)
      friends being set.  */
   block_input ();
 
+#ifdef HAVE_GTK3
+  /* read_minibuf assumes that calling Fx_focus_frame on a frame that
+     is already selected won't move the focus elsewhere, and thereby
+     disrupt any focus redirection to e.g. a minibuffer frame that
+     might be activated between that call being made and the
+     consequent XI_FocusIn/Out events arriving.  This is true whether
+     the focus is ultimately transferred back to the frame it was
+     initially on or not.
+
+     GTK 3 moves the keyboard focus to the edit widget's window
+     whenever it receives a FocusIn event targeting the outer window.
+     This operation gives rise to a FocusOut event that clears
+     device->focus_frame, which in turn prompts xi_handle_focus_change
+     to clear the display's focus frame.  The next FocusIn event
+     destined for the same frame registers as a new focus, which
+     cancels any focus redirection from that frame.
+
+     To prevent this chain of events from disrupting focus redirection
+     when the minibuffer is activated twice in rapid succession while
+     configured to redirect focus to a minibuffer frame, ignore frames
+     which hold the input focus and are connected to a minibuffer
+     window.  (bug#65116)*/
+
+  if (f == dpyinfo->x_focus_frame && !FRAME_HAS_MINIBUF_P (f))
+    return;
+#endif /* HAVE_GTK3 */
+
   if (FRAME_X_EMBEDDED_P (f))
     /* For Xembedded frames, normally the embedder forwards key
        events.  See XEmbed Protocol Specification at

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Yes that also fixes it.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello, Jim.

On Sun, Jan 14, 2024 at 08:33:03 -0600, Jim Rees wrote:
> Yes that also fixes it.

Thanks for the testing!

I'm closing the bug with this post, now.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

While Po's patch fixes the read-args focus bug, I now have a new bug. It
happens irregularly and I can't say for sure yet that it's caused by Po's
patch. I don't know what triggers it but it seems I need to have at least
two edit frames open.

What happens first is the mouse pointer disappears, but I can still edit.
After a while emacs hangs and ignores all input. A bit later it won't even
redisplay frames on X exposure.

Here is the stack when it hangs:

% sudo gdb -batch -ex bt -p 174496
[New LWP 174497]
[New LWP 174498]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
0x00007f7f6ee3e9d8 in pthread_sigmask () from /usr/lib/libc.so.6
#0  0x00007f7f6ee3e9d8 in pthread_sigmask () at /usr/lib/libc.so.6
#1  0x000055e30363ed64 in block_interrupt_signal ()
#2  0x000055e3036d3a2a in really_call_select ()
#3  0x000055e3036d3ee9 in thread_select ()
#4  0x000055e3036ec3e4 in xg_select ()
#5  0x000055e3036baaa2 in wait_reading_process_output ()
#6  0x000055e303634352 in read_char ()
#7  0x000055e303635b0d in read_key_sequence ()
#8  0x000055e303636999 in command_loop_1 ()
#9  0x000055e3036870a9 in internal_condition_case ()
#10 0x000055e30362a3d2 in command_loop_2 ()
#11 0x000055e303687027 in internal_catch ()
#12 0x000055e30362a374 in command_loop ()
#13 0x000055e30362d1c3 in recursive_edit_1 ()
#14 0x000055e30362d418 in Frecursive_edit ()
#15 0x000055e30356b311 in main ()
[Inferior 1 (process 174496) detached]

Note this is Po's patch on top of stock 29.1. If I get ambitious I'll try
building from master.

I would not normally report a bug with such sketchy information but I
thought you should know. If I figure out anything more I will make a proper
bug report.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Eli Zaretskii]

> Date: Sun, 14 Jan 2024 10:59:16 -0600
> From: Jim Rees <jim@rees.org>
> Cc: acm@muc.de, luangruo@yahoo.com, 65116@debbugs.gnu.org
> 
> What happens first is the mouse pointer disappears, but I can still edit.
> After a while emacs hangs and ignores all input. A bit later it won't even
> redisplay frames on X exposure.
> 
> Here is the stack when it hangs:
> 
> % sudo gdb -batch -ex bt -p 174496
> [New LWP 174497]
> [New LWP 174498]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> 0x00007f7f6ee3e9d8 in pthread_sigmask () from /usr/lib/libc.so.6
> #0  0x00007f7f6ee3e9d8 in pthread_sigmask () at /usr/lib/libc.so.6
> #1  0x000055e30363ed64 in block_interrupt_signal ()
> #2  0x000055e3036d3a2a in really_call_select ()
> #3  0x000055e3036d3ee9 in thread_select ()
> #4  0x000055e3036ec3e4 in xg_select ()
> #5  0x000055e3036baaa2 in wait_reading_process_output ()
> #6  0x000055e303634352 in read_char ()
> #7  0x000055e303635b0d in read_key_sequence ()
> #8  0x000055e303636999 in command_loop_1 ()
> #9  0x000055e3036870a9 in internal_condition_case ()
> #10 0x000055e30362a3d2 in command_loop_2 ()
> #11 0x000055e303687027 in internal_catch ()
> #12 0x000055e30362a374 in command_loop ()
> #13 0x000055e30362d1c3 in recursive_edit_1 ()
> #14 0x000055e30362d418 in Frecursive_edit ()
> #15 0x000055e30356b311 in main ()
> [Inferior 1 (process 174496) detached]

AFAIU, this backtrace just says that Emacs waits for some input, so it
isn't very informative.  The question is why it doesn't _get_ any
input?

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Eli Zaretskii]

> Cc: luangruo@yahoo.com, acm@muc.de, 65116@debbugs.gnu.org
> Date: Sun, 14 Jan 2024 19:17:13 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > % sudo gdb -batch -ex bt -p 174496
> > [New LWP 174497]
> > [New LWP 174498]
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/usr/lib/libthread_db.so.1".
> > 0x00007f7f6ee3e9d8 in pthread_sigmask () from /usr/lib/libc.so.6
> > #0  0x00007f7f6ee3e9d8 in pthread_sigmask () at /usr/lib/libc.so.6
> > #1  0x000055e30363ed64 in block_interrupt_signal ()
> > #2  0x000055e3036d3a2a in really_call_select ()
> > #3  0x000055e3036d3ee9 in thread_select ()
> > #4  0x000055e3036ec3e4 in xg_select ()
> > #5  0x000055e3036baaa2 in wait_reading_process_output ()
> > #6  0x000055e303634352 in read_char ()
> > #7  0x000055e303635b0d in read_key_sequence ()
> > #8  0x000055e303636999 in command_loop_1 ()
> > #9  0x000055e3036870a9 in internal_condition_case ()
> > #10 0x000055e30362a3d2 in command_loop_2 ()
> > #11 0x000055e303687027 in internal_catch ()
> > #12 0x000055e30362a374 in command_loop ()
> > #13 0x000055e30362d1c3 in recursive_edit_1 ()
> > #14 0x000055e30362d418 in Frecursive_edit ()
> > #15 0x000055e30356b311 in main ()
> > [Inferior 1 (process 174496) detached]
> 
> AFAIU, this backtrace just says that Emacs waits for some input, so it
> isn't very informative.  The question is why it doesn't _get_ any
> input?

Btw, I think you should submit a separate bug report about this, as
this issue is probably unrelated.  Unless you are saying that before
applying Po's patch this never happened to you.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

This only happens with Po's patch, not with unpatched 29.1 or with Alan's
patch. That's the only reason I mention it. I don't feel I have enough
information to make a separate bug report at this time.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Eli Zaretskii]

> Date: Sun, 14 Jan 2024 13:10:47 -0600
> From: Jim Rees <jim@rees.org>
> Cc: luangruo@yahoo.com, acm@muc.de, 65116@debbugs.gnu.org
> 
> This only happens with Po's patch, not with unpatched 29.1 or with Alan's
> patch. That's the only reason I mention it. I don't feel I have enough
> information to make a separate bug report at this time.

Po Lu, does your patch assume something that exists only on the master
branch?  If not, maybe there's some problem with your solution?

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 14 Jan 2024 13:10:47 -0600
>> From: Jim Rees <jim@rees.org>
>> Cc: luangruo@yahoo.com, acm@muc.de, 65116@debbugs.gnu.org
>> 
>> This only happens with Po's patch, not with unpatched 29.1 or with Alan's
>> patch. That's the only reason I mention it. I don't feel I have enough
>> information to make a separate bug report at this time.
>
> Po Lu, does your patch assume something that exists only on the master
> branch?  If not, maybe there's some problem with your solution?

No, it should be compatible with 29.1.  Jim, does your window manager
indicate whether the frame is focused in its window decorations, and if
so, are such indications active when Emacs appears to hang?

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu wrote:

  No, it should be compatible with 29.1.  Jim, does your window manager
  indicate whether the frame is focused in its window decorations, and if
  so, are such indications active when Emacs appears to hang?

Yes it does, and yes they are.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jim Rees <jim@rees.org> writes:

> Po Lu wrote:
>
>   No, it should be compatible with 29.1.  Jim, does your window manager
>   indicate whether the frame is focused in its window decorations, and if
>   so, are such indications active when Emacs appears to hang?
>
> Yes it does, and yes they are.

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 6cfb4034ed9..a7c547afd39 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1593,6 +1593,9 @@ xg_create_frame_widgets (struct frame *f)
 
   /* Use same names as the Xt port does.  I.e. Emacs.pane.emacs by default */
   gtk_widget_set_name (wtop, EMACS_CLASS);
+#if defined HAVE_XINPUT2 && defined HAVE_GTK3
+  gtk_widget_add_events (wtop, GDK_ALL_EVENTS_MASK);
+#endif /* HAVE_XINPUT2 && HAVE_GTK3 */
   gtk_widget_set_name (wvbox, "pane");
   gtk_widget_set_name (wfixed, SSDATA (Vx_resource_name));
 
Does this solve the problem?

Thanks for testing.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

No, that does not solve the problem.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jim Rees <jim@rees.org> writes:

> No, that does not solve the problem.

Nevermind, I set aside some time to debug this.  A missing unblock_input
was the culprit, which has now been fixed on master:

diff --git a/src/xterm.c b/src/xterm.c
index fe398171754..c8a43785564 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -28828,7 +28828,10 @@ x_focus_frame (struct frame *f, bool noactivate)
      window.  (bug#65116)*/
 
   if (f == dpyinfo->x_focus_frame && !FRAME_HAS_MINIBUF_P (f))
-    return;
+    {
+      unblock_input ();
+      return;
+    }
 #endif /* HAVE_GTK3 */
 
   if (FRAME_X_EMBEDDED_P (f))

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Jim Rees via Bug reports for GNU Emacs, the Swiss army knife of text editors]

So far so good. If you don't hear from me in the next couple of days
consider it fixed. Thanks.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 12 Jan 2024 21:44:11 +0000
>> Cc: 65116@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, acm@muc.de
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> Hello, Jim.
>> 
>> On Fri, Jan 12, 2024 at 12:57:42 -0600, Jim Rees wrote:
>> > Well that's a relief. I do have an unusual setup with detached minibuf and
>> > focus follows mouse. There has been a lot of churn in replace.el and frame.c
>> > lately and I keep hoping the bug will go away on its own. I don't really
>> > understand all the focus changes in the code but I do see why they are
>> > necessary.
>> 
>> > I have a workaround, I have bound this to a key and use it to re-focus to
>> > the minibuf so I can enter the 'to' text:
>> 
>> > (select-frame-set-input-focus (window-frame (minibuffer-window)))
>> 
>> > But that requires manual intervention so for now I'm sticking with 28.1.
>> 
>> I've been playing with the setup for an hour or two.  It seems that
>> performing some action in the minibuffer (say, M-x auto-revert-mode, but
>> anything will do) causes M-% to work properly.  But then, the moment the
>> mouse leaves the active frame or window (I'm not sure which), M-% no
>> longer works properly, until the next minibuffer action.
>> 
>> I know this isn't much help to you, but it should be a help to us,
>> tracking down what's going wrong.
>
> If this is WM-specific, maybe Po Lu (CC'ed) could help us understand
> what happens here?  Perhaps some message we expect from X is not being
> received in this scenario?

This is GTK3-specific.  I've installed a fix on master, please test.

bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf

[Alan Mackenzie]

Hello, Po.

On Sun, Jan 14, 2024 at 08:27:16 +0800, Po Lu wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> Date: Fri, 12 Jan 2024 21:44:11 +0000
> >> Cc: 65116@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, acm@muc.de
> >> From: Alan Mackenzie <acm@muc.de>

> >> Hello, Jim.

> >> On Fri, Jan 12, 2024 at 12:57:42 -0600, Jim Rees wrote:
> >> > Well that's a relief. I do have an unusual setup with detached minibuf and
> >> > focus follows mouse. There has been a lot of churn in replace.el and frame.c
> >> > lately and I keep hoping the bug will go away on its own. I don't really
> >> > understand all the focus changes in the code but I do see why they are
> >> > necessary.

> >> > I have a workaround, I have bound this to a key and use it to re-focus to
> >> > the minibuf so I can enter the 'to' text:

> >> > (select-frame-set-input-focus (window-frame (minibuffer-window)))

> >> > But that requires manual intervention so for now I'm sticking with 28.1.

> >> I've been playing with the setup for an hour or two.  It seems that
> >> performing some action in the minibuffer (say, M-x auto-revert-mode, but
> >> anything will do) causes M-% to work properly.  But then, the moment the
> >> mouse leaves the active frame or window (I'm not sure which), M-% no
> >> longer works properly, until the next minibuffer action.

> >> I know this isn't much help to you, but it should be a help to us,
> >> tracking down what's going wrong.

> > If this is WM-specific, maybe Po Lu (CC'ed) could help us understand
> > what happens here?  Perhaps some message we expect from X is not being
> > received in this scenario?

> This is GTK3-specific.  I've installed a fix on master, please test.

Thanks for this.  Thanks also for the detailed comment explaining the
fix.  I now understand where and why the redirected focus carefully
installed on the main frame was being removed.

I've tested it, with Jim's test case, and it works for me.

-- 
Alan Mackenzie (Nuremberg, Germany).