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

[Drew Adams]

> 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.