Re: query-replace-interactive not documented

[David Kastrup <dak@gnu.org>]

Richard Stallman <rms@gnu.org> writes:

>     > Using a space to end a variable name after `\,' is a clean solution.
> 
>     Using a space is fine, but not deleting it.
> 
> Yes, it should delete the space.  Users will find this natural once
> they know about it.  Many other programs have had such interfaces.

Wel, optional spaces in the middle of regexp are something that needs
extra explaining.  And the question is how to make that rule
consistent.  There are some Lisp expressions that are
"self-sufficient", like everything enclosed in parens or quotes, and
some that are ended by an incompatible character following, like
symbols.  Actually, I can't think about much except symbols here, and
maybe forms like 'symbol which end up as a list.

It does feel somewhat strange that the replacement expression
x + \,(1+ \#) + y;
would swallow a space, and even requiring something like
x + \,replace-count  + y;
is not particularly pretty.

>     Instead of deleting the space, in cases where the user DON'T want a
>     space between a variable value and the followed text, he can add
>     separators like the close paren in "\,(or variable)text".
> 
> That is much less convenient.

Somewhat (4 more letters), but it is also rarely needed.  The only
_variable_ identifier that is really defined in replacements is
replace-count, and I added the shorthand \# for what would amount to
\'replace-count already.  So we are basically just talking about
constants stored in Lisp symbols, and there is not much of an
incentive for using those: you can just write the contents in the
replacement string instead.

So I think we are talking about an additional rule that would be
required rather rarely in practice, has an easily available workaround
available, and that would either need to have special exceptions again
or would also impact expressions that are already properly bracketed
and don't need additional spaces, by far the most common occurence.

Have you taken a look at the DOC-string of the currently checked-in
version of query-replace-regexp?  I think the current behavior is, all
in all, clear, convenient and easily explained.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum