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#49963: 28.0.50; isearch failing in Dired after rectangle-mark-mode and query-replace Date: Wed, 11 Aug 2021 15:39:39 +0300 Message-ID: <83pmukduk4.fsf@gnu.org> References: <87k0kudsb8.fsf@mail.linkov.net> <83r1f1fmi2.fsf@gnu.org> <83lf59fh7q.fsf@gnu.org> <87h7fxxq19.fsf@gnus.org> <83bl65fdzq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15337"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49963@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net, laslydone@protonmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 11 14:40:09 2021 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 1mDnWj-0003na-9X for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 11 Aug 2021 14:40:09 +0200 Original-Received: from localhost ([::1]:58400 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mDnWh-0002LY-T1 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 11 Aug 2021 08:40:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34414) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mDnWc-0002LL-Bs for bug-gnu-emacs@gnu.org; Wed, 11 Aug 2021 08:40:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50500) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mDnWb-0008Nr-PX for bug-gnu-emacs@gnu.org; Wed, 11 Aug 2021 08:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mDnWb-0005LJ-MZ for bug-gnu-emacs@gnu.org; Wed, 11 Aug 2021 08:40:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Aug 2021 12:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49963 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 49963-submit@debbugs.gnu.org id=B49963.162868558220508 (code B ref 49963); Wed, 11 Aug 2021 12:40:01 +0000 Original-Received: (at 49963) by debbugs.gnu.org; 11 Aug 2021 12:39:42 +0000 Original-Received: from localhost ([127.0.0.1]:33813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDnWE-0005Ke-Fg for submit@debbugs.gnu.org; Wed, 11 Aug 2021 08:39:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDnWB-0005KP-MJ for 49963@debbugs.gnu.org; Wed, 11 Aug 2021 08:39:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57072) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mDnW5-00087U-5Q; Wed, 11 Aug 2021 08:39:29 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2527 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mDnW4-00014S-LP; Wed, 11 Aug 2021 08:39:28 -0400 In-Reply-To: (message from Stefan Monnier on Tue, 10 Aug 2021 16:37:22 -0400) 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" Xref: news.gmane.io gmane.emacs.bugs:211591 Archived-At: > From: Stefan Monnier > Cc: larsi@gnus.org, 49963@debbugs.gnu.org, juri@linkov.net, > laslydone@protonmail.com > Date: Tue, 10 Aug 2021 16:37:22 -0400 > > Eli Zaretskii [2021-08-10 19:42:17] wrote: > >> From: Stefan Monnier > >> Cc: Eli Zaretskii , 49963@debbugs.gnu.org, juri@linkov.net, > >> laslydone@protonmail.com > >> Date: Tue, 10 Aug 2021 11:56:58 -0400 > >> > >> Lars Ingebrigtsen [2021-08-10 17:44:50] wrote: > >> > Eli Zaretskii writes: > >> >> I meant can we please not use add-function and friends. Please? > >> > There isn't much difference between using add-function and add-hook most > >> > of the time (although here we trip over a `let' binding not doing what > >> > the author thought it did). > >> > >> FWIW, `add-hook` has the exact same problem with `let` (and we already > >> tripped against this exact same situation with `add-hook` and `let`). > > > > This is a misunderstanding of what bothers me. The problem is > > discoverability: add-function is not easily discoverable, if it is > > used on an internal function. > > I'm sorry, I don't understand. AFAIK it's used on variables (in the > present case it's used on the variable `isearch-filter-predicate`) > holding functions, not on internal functions. And if I've said instead This is a misunderstanding of what bothers me. The problem is discoverability: add-function is not easily discoverable, if it is used on an internal variable. then you'd understand? If so, please excuse my silly typo, and please reply to the amended text above. > > IOW, the documentation of C-s doesn't tell you that its operation > > could be affected by that "hook". > > You mean the doc of `C-s` should state that it's affected by > `isearch-filter-predicate`? > > Fine by me, but I don't know what this has to do with `add-function` > (`isearch-filter-predicate` existed before `add-function` was invented). It makes the rabbit hole much deeper and darker. Because even if and when I find that isearch-filter-predicate is involved in this (which isn't easy, see below), its "C-h v" shows the following gobbledygook: isearch-filter-predicate is a variable defined in ‘isearch.el’. Its value is #f(advice-wrapper :after-while #f(compiled-function (&rest args) #) wdired-isearch-filter-read-only) And that's the second try, after "M-: isearch-filter-predicate RET", a standard way of figuring out the values of variables,which curses thusly: #[128 "\300\302\"\205 ^@\300\301\"\207" [apply wdired-isearch-filter-read-only #[128 "\301\302\300!\"\207" [isearch-filter-predicate apply default-value] 4 " (fn &rest ARGS)"] nil] 4 nil] Why does wdired need to use add-function? why couldn't it simply put its own function on isearch-filter-predicate's value? The code in isearch.el is notoriously hard to debug, because it is written in many layers, uses a lot of function variables and indirect calls, and almost none of its important subroutines have any useful doc strings or comments. And stepping with Edebug through its code is also not easy because of the way Isearch reads input, which conflicts with Edebug's SPC-stepping. So tracking an issue related to isearch.el is an endless mess of guessing the next candidate for being part of the puzzle, following the chain of indirect calls through variables and hooks, then finding the next suspect, etc. etc. Using add-function on top of that makes a bad problem much worse. So I'm asking whether we could improve that by not using add-function. Bonus points for adding meaningful doc strings and/or comments to important isearch.el functions and variables so that one could easier find the possible suspects by following the code and the documentation instead of stepping blindly through complex code. TIA.