Re: query-replace-interactive not documented

[David Kastrup]

Juri Linkov <address@hidden> writes:

> David Kastrup <address@hidden> 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  <address@hidden>

        * 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