bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Josh
Subject: bug#14708: 24.2; query-replace-regexp when match and replacement are the same
Date: Tue, 25 Jun 2013 08:03:56 -0700

On Tue, Jun 25, 2013 at 7:10 AM, Drew Adams <address@hidden> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]