From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#71927: 29.4; ibuffer-do-isearch and ibuffer-do-isearch-regexp not prompting for input Date: Thu, 04 Jul 2024 21:46:52 +0300 Message-ID: <86y16h6llv.fsf@gnu.org> References: <86ikxltzhx.fsf@mail.linkov.net> <861q49a8vt.fsf@gnu.org> <86y16h8olf.fsf@gnu.org> <878qyh79ov.fsf@gmx.net> <86zfqxqi6e.fsf@mail.linkov.net> <87v81l5aal.fsf@gmx.net> <864j9581zr.fsf@gnu.org> <87r0c957v2.fsf@gmx.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37161"; mail-complaints-to="usenet@ciao.gmane.io" Cc: basil@contovou.net, 71927@debbugs.gnu.org, me@eshelyaron.com, kickingvegas@gmail.com, juri@linkov.net To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 04 20:48:14 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 1sPRV8-0009Np-5N for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 04 Jul 2024 20:48:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPRUv-0005or-LX; Thu, 04 Jul 2024 14:48:01 -0400 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 1sPRUu-0005lO-1u for bug-gnu-emacs@gnu.org; Thu, 04 Jul 2024 14:48:00 -0400 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 1sPRUt-00032C-QX for bug-gnu-emacs@gnu.org; Thu, 04 Jul 2024 14:47:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sPRUw-00021c-9m for bug-gnu-emacs@gnu.org; Thu, 04 Jul 2024 14:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Jul 2024 18:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71927 X-GNU-PR-Package: emacs Original-Received: via spool by 71927-submit@debbugs.gnu.org id=B71927.17201188487740 (code B ref 71927); Thu, 04 Jul 2024 18:48:02 +0000 Original-Received: (at 71927) by debbugs.gnu.org; 4 Jul 2024 18:47:28 +0000 Original-Received: from localhost ([127.0.0.1]:42985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sPRU9-00020R-AK for submit@debbugs.gnu.org; Thu, 04 Jul 2024 14:47:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sPRU7-00020D-UM for 71927@debbugs.gnu.org; Thu, 04 Jul 2024 14:47:12 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sPRTx-0002Tv-LL; Thu, 04 Jul 2024 14:47:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+KElX1sA3hHg34297fKpJ2UH/DPiV2hitHBefdb3/pE=; b=TTj9avH693hg WqmW6NGHL5ZJ7N0Fz5Fa77EtrslGLADeq2ZKVEpgR9upYpG6mUlPg7eVAjhU0yufdNS9zaWz/T7qL llhjuShi77LDbvnUyAudSonK2GJcqlN23PWzCeUKTkEdRfAaCmC4IE1vzgwg+Xsv9JFHaCvvPSPwG NL3dLjQnEURnXda2hY1TD1qy+RpI2W5p0HQlevYMYPZ3k5BVOcvo0zqhmtKXk+nihfchH3YLlJGX4 LdS76YON7U9zmrfNze8rC+f0piOFKidbJSwp+PyLURaMhxKk3ffGS0/VjmrQ55oYqggA/FkGN+XUi jbbtvL8FUu7mi1exo1J5ZA==; In-Reply-To: <87r0c957v2.fsf@gmx.net> (message from Stephen Berman on Thu, 04 Jul 2024 20:29:05 +0200) 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:288392 Archived-At: > From: Stephen Berman > Cc: juri@linkov.net, me@eshelyaron.com, kickingvegas@gmail.com, > 71927@debbugs.gnu.org, basil@contovou.net, jpw@gnu.org > Date: Thu, 04 Jul 2024 20:29:05 +0200 > > On Thu, 04 Jul 2024 21:07:36 +0300 Eli Zaretskii wrote: > > >> From: Stephen Berman > >> Cc: Eli Zaretskii , Eshel Yaron , > >> kickingvegas@gmail.com, 71927@debbugs.gnu.org, basil@contovou.net, > >> jpw@gnu.org > >> Date: Thu, 04 Jul 2024 19:36:34 +0200 > >> > >> On Thu, 04 Jul 2024 19:04:42 +0300 Juri Linkov wrote: > >> > >> >>>> FWIW, AFAICT everything is working correctly, it's just that the > >> >>>> "Operation finished" message hides the prompt. ibuffer-do-isearch > >> >>>> should tell define-ibuffer-op not to display that message, somehow. > >> >>> > >> >>> I don't see how this could be considered "correct": the "Operation > >> >>> finished" message is supposed to be shown only after the Isearch is > >> >>> finished in all the marked buffer, not before. It looks like we need > >> >>> a function that will not return until all the buffers where searched, > >> >>> because that's what define-ibuffer-op expects. Don't you agree? > >> > > >> > It intentionally uses 'no-recursive-edit' set to t, so ibuffer-do-isearch > >> > correctly exits immediately while leaving isearch-mode enabled. > >> > > >> >> The attached patch appears to DTRT, but I only tested it briefly. > >> >> ... > >> >> (define-ibuffer-op ibuffer-do-isearch () > >> >> "Perform a `isearch-forward' in marked buffers." > >> >> (:interactive () > >> >> - :opstring "searched in" > >> >> + :no-opstring t > >> > > >> > Thanks for the patch. I confirm this is the right thing to do. > >> > Maybe instead of :no-opstring would be better to use some special value > >> > like :opstring 'no? But I'm not sure if this is better than :no-opstring. > >> > >> Suppressing the message when :opstring has the value 'no is fine with > >> me. If Eli is willing to accept this approach, I can go ahead and > >> commit it (to master, presumably, since this is a longstanding issue). > > > > I already said this didn't sound the right solution here, and I > > explained why. I'd be interested in hearing counter-arguments, if > > there are any. > > I gave a mild counterargument upthread, that making > ibuffer-do-isearch{-regexp} defuns independent of define-ibuffer-op > seems like accepting the inadequacy of the latter instead of trying to > improve it. It is indeed inadequate for commands that just put Emacs in a special state and return, as opposed to commands that don't return before they did the complete job of operating on the marked buffers. > Also, I am not familiar enough with the ibuffer code to be > confident that I could implement I could implement the functionality > without using this macro, but someone else might be in a better position > to do that. Fair enough.