Subject: Match again in perform-replace

From: Juri Linkov <[email-masked]>
Date: Tue, 05 Apr 2022 20:16:19 +0300

[This is a spin-off from bug#14013 and bug#53758]

There is a long-standing bug in query-replace.
The optimization that uses `match-again` and `looking-at`
ignores search-related variables such as
isearch-search-fun-function, replace-re-search-function, etc.

Here's is a test case that demonstrates the problem in current master
with the recent addition of dired-isearch-search-filenames:

1. cd /tmp; touch file1; ln -s file1 file2
2. enter Wdired and move point to the beginning of file2
3. C-M-% .* RET foo RET
4. answer `n` when asked to replace `file2`

After that the remaining part of the same line is highlighted,
i.e. the part after "file2" (that is a symbolic link) in:

  file2 -> file1

This is because the `match-again` optimization uses `(looking-at ".*")`
after the previous replacement "file2" to ask about the next replacement
of " -> file1" that ignores isearch-search-fun-function.

Also in bug#53758 Dmitry explained that xref--query-replace-1
needed such a hack to let-bind isearch-filter-predicate
because of this problem in perform-replace that uses
`looking-at` instead of `replace-re-search-function`.

So now we have two cases that require fixing perform-replace.