From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: query-replace-regexp-eval is quite nice, but... Date: 02 Feb 2004 13:17:25 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200402021216.i12CGdKb015329@beta.mvs.co.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: sea.gmane.org 1075731226 24326 80.91.224.253 (2 Feb 2004 14:13:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 2 Feb 2004 14:13:46 +0000 (UTC) Cc: schwab@suse.de, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Feb 02 15:13:39 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AnepX-00014b-00 for ; Mon, 02 Feb 2004 15:13:39 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AnepW-0000IQ-00 for ; Mon, 02 Feb 2004 15:13:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AneBK-0006Xa-9H for emacs-devel@quimby.gnus.org; Mon, 02 Feb 2004 08:32:06 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Andwl-0004VT-Si for emacs-devel@gnu.org; Mon, 02 Feb 2004 08:17:03 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AnddY-0001rU-Fa for emacs-devel@gnu.org; Mon, 02 Feb 2004 07:57:43 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AndUH-0000gB-Nb for emacs-devel@gnu.org; Mon, 02 Feb 2004 07:47:37 -0500 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1AndSp-0004Wk-VE; Mon, 02 Feb 2004 07:46:08 -0500 Original-To: "Ehud Karni" In-Reply-To: <200402021216.i12CGdKb015329@beta.mvs.co.il> Original-Lines: 60 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19655 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19655 --=-=-= "Ehud Karni" writes: > On Mon, 02 Feb 2004 11:24:34 +0100, Andreas Schwab wrote: > > > > David Kastrup writes: > > > > [snip] > > > > > > So the idea is to build your replacement string with Lisp, and this > > > is quite an excellent thing. It is completely defeated because the > > > replacement is then done non-literally. Which means that if \0 > > > would have matched \footnote, replacing the string just with \0 (which > > > one would expect to do nothing in effect) will barf because the > > > regexp replacer will not know what \f is supposed to be. > > > > I agree this is a bug. > > > > > Is there anybody that would make a case for a non-literal > > > replacement? If not, is there anybody with enough of a clue to find > > > out how to fix this? I have taken a look at perform-replace, but it > > > does not seem to offer an option for literal replacement for > > > regexps. Should we add one? > > > > Currently, perform-replace uses literal replacement for all non-regexp > > searches, and non-literal otherwise. What we could do is offer a special > > version of match-string that quotes backslashes and use that in > > replace-match-string-symbols. > > How about checking regexp-flag (which is bound by `perform-replace') ? > > Assuming your "literal" result string (containing \n) is STR you can > add something like this to your lisp: > > (if regexp-flag > (regexp-quote STR) > STR) "add something like this to my lisp"? query-replace-regexp-eval is an interactive function! Even if it weren't, there is no point in having two substitution mechanisms employed after another. I have cobbled together the following minimal-invasive patch. The new argument-option of regexp-eval is not documented but obvious. Since no other args are documented, either, with perform-replace, this does not seem to do much harm and it won't affect existing use of it. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment *** replace.el.~1.166.~ 2003-09-08 17:57:00.000000000 +0200 --- replace.el 2004-02-02 13:07:58.000000000 +0100 *************** *** 223,229 **** (if (and transient-mark-mode mark-active) (region-end))))) (perform-replace regexp (cons 'replace-eval-replacement to-expr) ! t t delimited nil nil start end)) (defun map-query-replace-regexp (regexp to-strings &optional n start end) "Replace some matches for REGEXP with various strings, in rotation. --- 223,229 ---- (if (and transient-mark-mode mark-active) (region-end))))) (perform-replace regexp (cons 'replace-eval-replacement to-expr) ! t 'literal delimited nil nil start end)) (defun map-query-replace-regexp (regexp to-strings &optional n start end) "Replace some matches for REGEXP with various strings, in rotation. *************** *** 1057,1063 **** (case-fold-search (and case-fold-search (string-equal from-string (downcase from-string)))) ! (literal (not regexp-flag)) (search-function (if regexp-flag 're-search-forward 'search-forward)) (search-string from-string) (real-match-data nil) ; the match data for the current match --- 1057,1063 ---- (case-fold-search (and case-fold-search (string-equal from-string (downcase from-string)))) ! (literal (or (not regexp-flag) (eq regexp-flag 'literal))) (search-function (if regexp-flag 're-search-forward 'search-forward)) (search-string from-string) (real-match-data nil) ; the match data for the current match --=-=-= Since the current behavior is clearly wrong, the fix does not cause any incompatibilities elsewhere, and the semantics are the obvious ones as already documented, I'll just check it in. If one wants to force more complicated things onto people, one can still change stuff (including the documentation), but for the current docs this behavior seems correct. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel --=-=-=--