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-interactive not documented Date: 16 Jun 2004 11:23:32 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040528.181649.25475113.wl@gnu.org> <200405291737.i4THbPJ06689@raven.dms.auburn.edu> <873c5jug73.fsf@mail.jurta.org> <87oenqa4lu.fsf@mail.jurta.org> <873c51w5rq.fsf@mail.jurta.org> <87659snbd8.fsf@mail.jurta.org> <878yeoadpd.fsf@mail.jurta.org> <87wu27exh0.fsf@mail.jurta.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1087377855 6878 80.91.224.253 (16 Jun 2004 09:24:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 Jun 2004 09:24:15 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jun 16 11:24:02 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 1BaWeH-00007c-00 for ; Wed, 16 Jun 2004 11:24:01 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BaWeH-00080r-00 for ; Wed, 16 Jun 2004 11:24:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BaWfG-0000pT-FA for emacs-devel@quimby.gnus.org; Wed, 16 Jun 2004 05:25:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BaWey-0000nn-CD for emacs-devel@gnu.org; Wed, 16 Jun 2004 05:24:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BaWex-0000nN-Mg for emacs-devel@gnu.org; Wed, 16 Jun 2004 05:24:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BaWex-0000nK-EH for emacs-devel@gnu.org; Wed, 16 Jun 2004 05:24:43 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BaWdq-0007Gj-Hf for emacs-devel@gnu.org; Wed, 16 Jun 2004 05:23:34 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BaWdp-0003ms-O3; Wed, 16 Jun 2004 05:23:34 -0400 Original-To: Juri Linkov In-Reply-To: <87wu27exh0.fsf@mail.jurta.org> Original-Lines: 85 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 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:25028 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:25028 Juri Linkov writes: > David Kastrup writes: > >> Another option may be > >> \`read-expression optionally followed by ' which gives us > >> > >> \\footnote{\\label{fn:\`replace-count'}} > >> > >> as well as > >> > >> \\footnote{\\label{fn:\`(or replace-count)}} > >> > >> \` has somewhat more of a "will be evaluated later" scent and it has > >> the advantage that it is somewhat natural to match it up with ' in > >> case we need to explicitly end the read expression. > > Perhaps \` is a better symbol than \', but having a special > meaning of ' following the expression seems wrong. This is > an additional rule that the user should learn, and it may produce > undesirable results when users forget this rule and put ' with > the intention to use it in the replacement. What about the \, proposal with a single optional additional space following? Most people are comfortable with such redundant spaces and don't write things like (format"%3d"27) Sure, it is an extra rule, but more natural than the \`...' thing. > > Ok, here is the whole ugly thing: it certainly won't interfere > > with programming since it does all the work in the interactive > > spec (see C-x ESC ESC for the show. BTW, can anybody tell me how > > the command history manages to record the last two arguments > > unevaluated? I can't for the life of me figure out how this > > works), so certainly no security risk. > > I think moving the code into the interactive spec is not needed. It is what query-replace-regexp-eval does, too. > There is no security risk in having it in the function body, because > the `query-flag' argument of `perform-replace' is t, which means > that even when the function `query-replace-regexp' is called > non-interactively the user can see the replacement string and type > `y' if he agrees with it. At the time you see the replacement string, the evaluation has already occured. > > If somebody has a good suggestion how one could get rid of > > replace-requote in the command history, it would be nice to hear. > > But I really think that \`"\\3"' should deliver a _verbatim_ \3, > > or we could have written \`\3' in the first place. > > This imposes artificial restrictions on what the user can do. No, it doesn't. > The user may want to construct a replacement string with > backreferences in the Lisp expression. That's what the symbols \1 \2 \3 are for. > I think that only the user should decide whether he wants a verbatim > \3 or its replacement. That's why he has both "\\3" and \3 at his disposal. > He can add backslashes for the literal meaning and write \`"\\\\3"' > instead of \`"\\3"'. But he can't "add backslashes" for a string returned by (match-string) or the equivalent \1: it is quite wrong to reinterpret backslashes in a matched string if all I want is to use it as part of a replacement. We had this discussion once already for query-replace-regexp-eval. It was what prompted the change 2004-02-02 David Kastrup * replace.el (perform-replace): Allow 'literal argument in regexp-flag to indicate literal replacement. (query-replace-regexp-eval): Use it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum