From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#65116: 29.1; query-replace-read-args fails reading second arg in detached minibuf Date: Sat, 13 Jan 2024 13:47:32 +0000 Message-ID: References: <831qalivwr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23920"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jim@rees.org, 65116@debbugs.gnu.org To: Eli Zaretskii , Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 13 14:48:21 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rOeN3-0005x6-K4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Jan 2024 14:48:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rOeMq-0000un-MP; Sat, 13 Jan 2024 08:48:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rOeMl-0000uX-NK for bug-gnu-emacs@gnu.org; Sat, 13 Jan 2024 08:48:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rOeMl-0005Hw-EO for bug-gnu-emacs@gnu.org; Sat, 13 Jan 2024 08:48:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rOeMk-00024I-0u for bug-gnu-emacs@gnu.org; Sat, 13 Jan 2024 08:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jan 2024 13:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65116 X-GNU-PR-Package: emacs Original-Received: via spool by 65116-submit@debbugs.gnu.org id=B65116.17051536607823 (code B ref 65116); Sat, 13 Jan 2024 13:48:01 +0000 Original-Received: (at 65116) by debbugs.gnu.org; 13 Jan 2024 13:47:40 +0000 Original-Received: from localhost ([127.0.0.1]:38759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOeMN-000224-O5 for submit@debbugs.gnu.org; Sat, 13 Jan 2024 08:47:40 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:12950) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rOeML-00021F-EP for 65116@debbugs.gnu.org; Sat, 13 Jan 2024 08:47:38 -0500 Original-Received: (qmail 8189 invoked by uid 3782); 13 Jan 2024 14:47:32 +0100 Original-Received: from acm.muc.de (p4fe15740.dip0.t-ipconnect.de [79.225.87.64]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 13 Jan 2024 14:47:32 +0100 Original-Received: (qmail 29181 invoked by uid 1000); 13 Jan 2024 13:47:32 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:278126 Archived-At: 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 , acm@muc.de > > > From: Alan Mackenzie > > > 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).