Re: query-replace-regexp-eval is quite nice, but...

[David Kastrup <dak@gnu.org>]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > The description tells us
> >
> > [...]
> >
> >     TO-EXPR is a Lisp expression evaluated to compute each
> >     replacement.  It may reference `replace-count' to get the number
> >     of replacements already made.  If the result of TO-EXPR is not a
> >     string, it is converted to one using `prin1-to-string' with the
> >     NOESCAPE argument (which see).
> >
> >     For convenience, when entering TO-EXPR interactively, you can use
> >     `\&' or `\0' to stand for whatever matched the whole of REGEXP,
> >     and `\N' (where N is a digit) to stand for whatever matched the
> >     Nth `\(...\)' in REGEXP.  Use `\#&' or `\#N' if you want a number
> >     instead of a string.
> >
> > 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.

But that means only that you get \0 and its ilk quoted.  The idea of
query-replace-regexp-eval is to build your replacement string
yourself.  And I won't get anything else quoted then.

I'll be perfectly able to enter
(concat "buzz" &1 &2)
instead of "buzz\\1\\2".

Really, I don't see any purpose whatsoever to do a non-literal
replacement here: all building blocks that a non-literal string would
be able to access are equally available in a form convenient for
replacements.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum