bug#23484: 25.1.50; undo doesn't work properly in xref-query-replace-in-results

[Juri Linkov]

>> So I see your aim is to use regexp replacements without regexps,
>> i.e. with only a list of region boundaries like is used by
>> region-noncontiguous-p in perform-replace.
>
> This may sound crazy, but shouldn't just using region-extract-function to
> return the list of region bounds work? FROM-STRING can then be `.*' without
> a problem.

By default .* tries to match whole lines.  For partial matches you need
to use a combination of goto-line and BOUND arg of re-search-forward.

But I still don't see a case where a search regexp used to find matches
in the *xref* buffer can't be re-used in xref-query-replace-in-results.

I tried ‘xref-find-definitions’ with a string identifier, then typed ‘r’
in the *xref* buffer - it asked “Xref query-replace (regexp) (default .*): ”,
then I typed RET and entered a replacement string, but eventually
it failed with “user-error: No suitable matches here”.

Then I thought that maybe you meant the case of ‘xref-find-apropos’
that might find quite different strings with partial matches of
the original pattern, but its replacements fail with the same
“No suitable matches here”.

It's difficult to find a solution without a real use case.

>> I guess this could be
>> achieved with more hacking in real-match-data (maybe to use a layer
>> like replace-match-data).
>
> A lot code in perform-replace is really beyond my comprehension, but why
> would the undo code muck around with replaying match data? It could just as
> well repeat the searches.

Maybe undo could use a search function too.  And with using
a search function should also avoid the need to disable
query-replace-lazy-highlight in xref--query-replace-1.

But it seems there is no hurry in fixing undo because undo of replacements
is a new feature existing only in master, not in the release branch.

If you are looking for a solution for the next release, I recommend
to not expose .* in the minibuffer to the users - that causes too many
problems.  Either leave the initial FROM regexp empty, so the user types
an explicit string, or don't ask FROM at all, using the same regexp
provided to find matches in the *xref* buffer, thus removing all tricks
with isearch-filter-predicate/replace-re-search-function, i.e. since the
.* replacement is not a release-ready feature, just continue its development
in master.