Re: `read--expression' and `read-minibuffer'

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> That's not a real problem, but that's the only place/case where I
> can see an argument for a "variant" behavior (completion against
> both function and variable names at that position too).

For S-exps in general, we can't provide much completion, and we
certainly shouldn't provide completion against function names and
variable names.

An S-exp is like an XML tree.  An Elisp expression is like a XHTML tree
(i.e. it's a particular kind of XML that is expected to follow
a particular schema).  Yes, it's also an XML tree, but if all you know
is that you're typing an XML tree, providing any completion based on
XHTML identifiers is just bogus.

> The non-"internal" function `read-minibuffer' is not very
> reasonable, and is essentially a vestige, at this point.

Ah, so that's your complaint.  Why don't you make a bug-report about
that one, pointing out exactly what are its shortcomings.  But do
remember: it's a function meant for S-exps, i.e. random data represented
in a form suitable for the Lisp reader, with no assumption like an
expectation that it be related to Elisp code.

> We can do better, and better is already available:
> `read--expression'.  Some such function should now be
> available non-"internally".

Now I'm confused.  If you want a function to read an Elisp expression,
indeed read--expression might be your solution.  Then make a bug report
asking for it to be renamed.

> If you want to (1) rename the current `read--expression' to
> `read-expression-for-eval' and (2) create a variant `read-expression'
> (which is for both eval and not), please go ahead.

I have no idea what a "read-expression not for eval" would mean or look like.

`read--expression' already couldn't care less whether you'll pass the
result to `eval' or not.  All it cares about is that it provides useful
behavior (eldoc, completion, indentation) under the assumption that the
user is typing something that is (more or less) valid Elisp code, rather
than random data.

> 1. That's not a good reason to make it "internal".

I already said that it's internal for no particular reason.  So at this
point I'll just PLONK


        Stefan