From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Josh Newsgroups: gmane.emacs.bugs Subject: bug#14708: 24.2; query-replace-regexp when match and replacement are the same Date: Tue, 25 Jun 2013 08:03:56 -0700 Message-ID: References: <7E039918541B4C4183BFDB8F015C74300E8E80@WCL-EXCH02.wcl.local> <7E039918541B4C4183BFDB8F015C74300E9E08@WCL-EXCH02.wcl.local> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372173040 25350 80.91.229.3 (25 Jun 2013 15:10:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2013 15:10:40 +0000 (UTC) Cc: 14708@debbugs.gnu.org, Ed Avis To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 25 17:10:40 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UrUt8-0002aO-Cg for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Jun 2013 17:10:34 +0200 Original-Received: from localhost ([::1]:36916 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrUt7-0005g6-Tg for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Jun 2013 11:10:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrUt1-0005aC-Oc for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2013 11:10:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrUsv-0006lo-9m for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2013 11:10:27 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46265) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrUnm-0004UO-RT for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2013 11:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1UrUnm-0005jg-0p for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2013 11:05:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Josh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Jun 2013 15:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14708 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14708-submit@debbugs.gnu.org id=B14708.137217267621999 (code B ref 14708); Tue, 25 Jun 2013 15:05:01 +0000 Original-Received: (at 14708) by debbugs.gnu.org; 25 Jun 2013 15:04:36 +0000 Original-Received: from localhost ([127.0.0.1]:40581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UrUnL-0005ik-CJ for submit@debbugs.gnu.org; Tue, 25 Jun 2013 11:04:36 -0400 Original-Received: from mail-qa0-f50.google.com ([209.85.216.50]:42745) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UrUnI-0005iV-8V for 14708@debbugs.gnu.org; Tue, 25 Jun 2013 11:04:32 -0400 Original-Received: by mail-qa0-f50.google.com with SMTP id l18so688975qak.2 for <14708@debbugs.gnu.org>; Tue, 25 Jun 2013 08:04:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=I9L+CLRvCmIM++Bl+u3yK3KXsnW746arnMkFBg3mRx0=; b=AK/MOaMvFoovLxI3KNwVCm44PlfLuUiU1dxm81WNtzhQiycak4wC7zY2yFF6LrciAW 5UiX1VqRJwyvfjsYUtCiaZwywgDINm5elLbzXL1Ik1iLJhxJ6eCoyI7QcTNx8CQmNrNH skRGScy3IKiAUNL/7Q7JcB9hlJkX+ua9zj6nmp3UKLSWWHQ0vAZsggreO575iK09Eg6n B4tBsTJKxC9ztl2asnfRKIN5Bu9AhUqP6WwOZS/ON4MVgjrBj5tQ43uoyDg8HGjK0d/b PluRaoIlu6KMBsiDfO2Hi4wcXkOJz26ZFNgTCWzCFeFdL4y+SPKEHqoDDiLH0y802W0R xw1w== X-Received: by 10.49.29.106 with SMTP id j10mr33064349qeh.37.1372172666616; Tue, 25 Jun 2013 08:04:26 -0700 (PDT) Original-Received: by 10.49.35.206 with HTTP; Tue, 25 Jun 2013 08:03:56 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: fHvL5CoiLTjWAoINWvCb_66yw3g X-Gm-Message-State: ALoCoQlxR8ahHXIHZAYV+Y07zd7/NAcaFCPwFV5ikLut+D2PQrQ9tI1E9MjOyfvU+RMP9Xjy6UOq X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:75567 Archived-At: On Tue, Jun 25, 2013 at 7:10 AM, Drew Adams 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 woul= dn't >> even notice. The user asked for confirmation of each change to end up wi= th >> 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 (th= ough >> surely a simple search without replacement would be better). But even th= en >> it would be enough just to flag up one case where match=3Dreplacement, n= ot >> 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 r= est. > > 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 oc= currence precisely matches the replacement string. > > This could be an optional behavior, but it certainly should not simply re= place the longstanding behavior. > > Why? Because query replacing is not just about replacing. It can be abo= ut checking occurrences (all of them). It can involve stopping and doing s= omething (e.g. editing the occurrence in a different way from the replaceme= nt text, or editing surrounding text). And that "stopping" can be either v= ia recursive edit (allowing q-r resuming) or simply stopping altogether (an= d perhaps restarting, at the same spot or elsewhere). > > In sum, there is a lot more to a q-r interaction than simply y/n replacem= ent. 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 reque= st. But please do not just replace the existing, rich behavior. Yes, exactly.