bug#14708: 24.2; query-replace-regexp when match and replacement are the same

[Josh <josh@foxtail.org>]

On Tue, Jun 25, 2013 at 7:10 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> I wouldn't say that the regexp in this case is broken - only suboptimal. The
>> user entered something correct, to replace all sequences of spaces by a
>> single space. If done as a global replace without confirmation, you wouldn't
>> even notice. The user asked for confirmation of each change to end up with
>> the right text in the buffer, not as an academic exercise in finding the
>> best possible regexp.
>>
>> So prompting for each no-op match is not really helping the user. I can see
>> that sometimes you might use query-replace-regexp as a debugging aid (though
>> surely a simple search without replacement would be better). But even then
>> it would be enough just to flag up one case where match=replacement, not
>> request y or n for each one, since they are all identical. (Here I am
>> assuming no capturing groups.)
>>
>> So maybe the answer is to flag the first no-op match but then skip the rest.
>
> Haven't been following this thread, so excuse if I misunderstand.
>
> It would be wrong, IMHO, to simply skip ANY matches, e.g., because the occurrence precisely matches the replacement string.
>
> This could be an optional behavior, but it certainly should not simply replace the longstanding behavior.
>
> Why?  Because query replacing is not just about replacing.  It can be about checking occurrences (all of them).  It can involve stopping and doing something (e.g. editing the occurrence in a different way from the replacement text, or editing surrounding text).  And that "stopping" can be either via recursive edit (allowing q-r resuming) or simply stopping altogether (and perhaps restarting, at the same spot or elsewhere).
>
> In sum, there is a lot more to a q-r interaction than simply y/n replacement.  Do not mess up what has already been available.  If you like, provide an option (on the fly via a key or via a user option) to do what you request.  But please do not just replace the existing, rich behavior.

Yes, exactly.