GNU bug report logs -
#65116
29.1; query-replace-read-args fails reading second arg in detached minibuf
Previous Next
Reported by: Jim Rees <jim <at> rees.org>
Date: Sun, 6 Aug 2023 19:05:01 UTC
Severity: normal
Found in version 29.1
Done: Alan Mackenzie <acm <at> muc.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> 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).
This bug report was last modified 1 year and 131 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.