GNU bug report logs -
#53758
28.0.91; Recursive edit during dired-do-find-regexp-and-replace breaks isearch
Previous Next
Reported by: sbaugh <at> catern.com
Date: Thu, 3 Feb 2022 19:12:02 UTC
Severity: normal
Merged with 53759,
53760,
53761
Found in version 28.0.91
Fixed in version 29.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
Message #10 received at 53758 <at> debbugs.gnu.org (full text, mbox):
> 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'?
This bug report was last modified 3 years and 104 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.