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

[David Kastrup]

"Ehud Karni" <address@hidden> writes:

> On Mon, 02 Feb 2004 11:24:34 +0100, Andreas Schwab <address@hidden> wrote:
> >
> > David Kastrup <address@hidden> 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.

txt8wvQVBdTgy.txt
Description: Text Data

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