"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.