bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#53758: 28.0.91; Recursive edit during dired-do-find-regexp-and-repla


From: Dmitry Gutov
Subject: 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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]