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

[Drew Adams <drew.adams@oracle.com>]

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