Re: query-replace-interactive not documented

[David Kastrup]

Richard Stallman <address@hidden> writes:

>     So what is the rule?  The problem is that currently I just use
>     read-from-string, and that can't distinguish between
>     'symbol
>     and
>     (quote symbol)
> 
> I had not been thinking about that because I was assuming that the
> reader itself would swallow the space.  However, in writing my code
> I found it does not.  Indeed I forgot to handle this distinction.
> 
> Since the value is supposed to be a string, perhaps neither of these
> cases matters much.  However, I think it would be easy to distinguish
> them by testing whether the expression began with an open-paren.
> 
>                           ;; Swallow a space after a symbol
>                           ;; if there is a space.
>                           (if (and (or (symbolp (car pos))
>                                        ;; Swallow a space after 'foo
>                                        ;; but not after (quote foo).
>                                        (and (eq (car-safe (car pos)) 'quote)
>                                             (= ?\( (aref to-string 0))))
>                                    (equal " " (substring to-string (cdr pos)
>                                                          (1+ (cdr pos)))))

Well, and then we have vectors and strings (which again usually are
properly matched).  In order to allow an optional space only where it
"is needed", one would probably have to use one's own STREAM function
by using `read' instead of `read-from-string':

read is a built-in function in `C source code'.
(read &optional STREAM)

Read one Lisp expression as text from STREAM, return as Lisp object.
If STREAM is nil, use the value of `standard-input' (which see).
STREAM or the value of `standard-input' may be:
[...]
 a function (call it with no arguments for each character,
     call it with a char as argument to push a char back)
[...]

and record when a trailing space gets unread again.  And then one
still has to explain the behavior in the DOC string.

I just doubt that the gain in convenience is worth the trouble.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum