From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#14708: 24.2; query-replace-regexp when match and replacement are the same Date: Tue, 25 Jun 2013 07:10:20 -0700 (PDT) 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=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372169473 14218 80.91.229.3 (25 Jun 2013 14:11:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2013 14:11:13 +0000 (UTC) Cc: 14708@debbugs.gnu.org To: Ed Avis , jlf@foxtail.org, monnier@iro.umontreal.ca Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 25 16:11:13 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 1UrTxg-0008TV-Jn for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Jun 2013 16:11:12 +0200 Original-Received: from localhost ([::1]:36146 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTxg-00030d-28 for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Jun 2013 10:11:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTxY-00030H-Df for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2013 10:11:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrTxX-0001Kj-4z for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2013 10:11:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTxX-0001Ke-1S for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2013 10:11:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1UrTxW-00043u-G8 for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2013 10:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Jun 2013 14:11:02 +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.137216943415573 (code B ref 14708); Tue, 25 Jun 2013 14:11:02 +0000 Original-Received: (at 14708) by debbugs.gnu.org; 25 Jun 2013 14:10:34 +0000 Original-Received: from localhost ([127.0.0.1]:40488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UrTx3-000433-QR for submit@debbugs.gnu.org; Tue, 25 Jun 2013 10:10:34 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:31704) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1UrTx0-00042i-FL for 14708@debbugs.gnu.org; Tue, 25 Jun 2013 10:10:31 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5PEANSl007161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Jun 2013 14:10:24 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5PEAKjN006221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 14:10:22 GMT Original-Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5PEAKQF006209; Tue, 25 Jun 2013 14:10:20 GMT In-Reply-To: <7E039918541B4C4183BFDB8F015C74300E9E08@WCL-EXCH02.wcl.local> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] 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:75560 Archived-At: > 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 would= n't > even notice. The user asked for confirmation of each change to end up wit= h > the right text in the buffer, not as an academic exercise in finding the > best possible regexp. >=20 > So prompting for each no-op match is not really helping the user. I can s= ee > that sometimes you might use query-replace-regexp as a debugging aid (tho= ugh > surely a simple search without replacement would be better). But even the= n > it would be enough just to flag up one case where match=3Dreplacement, no= t > request y or n for each one, since they are all identical. (Here I am > assuming no capturing groups.) >=20 > So maybe the answer is to flag the first no-op match but then skip the re= st. 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 occu= rrence precisely matches the replacement string. This could be an optional behavior, but it certainly should not simply repl= ace 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 som= ething (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 replacemen= t. Do not mess up what has already been available. If you like, provide a= n 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.