Re: A better UI than perform-replace

[Juri Linkov]

>> I think we need to keep both the current multi-file query-replace and
>> multi-occur, and extend the latter with query-replace capabilities,
>> (thus a better mode name would be 'occur-query-replace-mode') because
>> the current multi-file query-replace is already used in several places
>> such as tags-query-replace.  Then for xref you could take any of them.
>
> Yes, we'll need a separate occur-??? query-replace function that takes
> a set of files as an argument.
>
> It would be cool if both query-replace functions had the same calling
> convention, and we could choose the user-preferred one based on
> a global variable.
>
>> PS: I noticed a FIXME in xref--query-replace-1, and I wonder why can't you
>> use `multi-query-replace-map' the same way as it's used in 
>> tags-query-replace?
>
> Last time I tried, it wasn't a drop-in replacement: with
> `multi-query-replace-map', `perform-replace' really expects to be called
> once per buffer, and it would've been really inconvenient in the initial
> implementation. Less so with the current one, though.

Then instead of tags-loop-continue/next-file currently used by etags.el,
we could have a much simpler function multi-query-replace with bufs arg.