GNU bug report logs - #53758
28.0.91; Recursive edit during dired-do-find-regexp-and-replace breaks isearch

Previous Next

Full log

Message #13 received at 53758 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: sbaugh <at> catern.com, 53758 <at> debbugs.gnu.org
Subject: Re: bug#53758: 28.0.91; Recursive edit during
 dired-do-find-regexp-and-replace breaks isearch
Date: Mon, 7 Feb 2022 05:03:38 +0200

Hi Juri,

On 06.02.2022 19:44, Juri Linkov wrote:
>> isearch-forward (C-s) while in a recursive edit (C-r) triggered from
>> dired-do-find-regexp-and-replace (Q in a dired buffer) always fails to
>> find any matches for any string, even if there are matches in the
>> buffer.
>>
>> Steps to reproduce:
>> 1. Open a dired buffer in a directory containing at least one file which
>> contains some text (e.g. "Hello world")
>> 2. Run dired-do-find-regexp-and-replace to replace "Hello" with
>> "Goodbye" ("Q Hello RET Goodbye RET"); this will switch buffers
>> to the first matching file.
>> 3. Type C-r to enter a recursive edit (I'm guessing this runs
>> (recursive-edit)?)
>> 4. At the start of the buffer, run isearch-forward searching for "world"
>> ("C-s world RET")
>> 5. Note that the isearch fails despite "world" being in the buffer.
>>
>> For what it's worth, this interestingly doesn't happen with
>> project-query-regexp-replace (which also does multi-file query-replace).
> This is because of these lines in xref--query-replace-1:
> 
>           ;; Counteract the "do the next match now" hack in
>           ;; `perform-replace'.  And still, it'll report that those
>           ;; matches were "filtered out" at the end.
>           (isearch-filter-predicate
>            (lambda (beg end)
>              (and current-beg
>                   (>= beg current-beg)
>                   (<= end current-end))))
> 
> Dmitry, could you please explain the comment above.
> What I don't understand is where this
> "the next match now" hack is in `perform-replace'?

It's referring to the comment on lines starting with 2938 and the 
subsequent code which uses 'looking-at' instead of 
replace-re-search-function.

Here's that comment in full:

	  ;; Otherwise, if matching a regular expression, do the next
	  ;; match now, since the replacement for this match may
	  ;; affect whether the next match is adjacent to this one.
	  ;; If that match is empty, don't use it.

I'm not sure why the result would be different between 
dired-do-find-regexp-and-replace and project-query-regexp-replace, though.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.