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

[Drew Adams <drew.adams@oracle.com>]

> >> Because it is tailored for that use case.  The kind of completion
> >> it provides for instance assumes the S-exp is an Elisp expression.
> >
> > Of course it is an Elisp expression.  It does not follow that
> > the Elisp expression that has been read will then be _evaluated_.
> 
> In this thread, Stefan is defining an "Elisp expression" to be
> precisely an S-exp that is intended for `eval'.

He may be.  But that does not really correspond to the effect of
`read--expression'.  There is nothing in its behavior that limits
what is read to expressions that are intended to be evaluated.

> > Completion can be used and useful when constructing an Elisp
> > expression to be read, regardless of whether the expression
> > that is read will be evaluated, or can be evaluated without
> > error.
> 
> So a variant of `read--expression' could be written that does a subset
> of that completion appropriate to the more general context of entering
> an S-exp.  It might for instance be a flag passed to `read--expression'.

See above.  What is read and returned is an arbitrary sexp, not
one that is supposedly intended only for evaluation.

Perhaps you are referring to the fact that after `(' a symbol is
completed against only function names, instead of against both
function and variable names?

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).

Or perhaps you are referring to the fact that `read--expression'
runs `eval-expression-minibuffer-setup-hook' functions at the
outset?

If you want to bother creating a variant for completing both
function and variable symbols, and for not running that
eval-intended hook, I don't have a problem with that.

The point is to get a reasonably behaving read function for
sexps that is not branded "internal".

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

And there is little sense in otherwise asking users to roll
their own, e.g., using just `read-from-minibuffer' with
`read-expression-map' and `read-expression-history'.

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

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.

Or if you want to roll those together, distinguishing the
behaviors by an optional arg, please go ahead.

> This answers your original question: it's internal because we are
> still discovering the use cases and desirable interface for it.

1. That's not a good reason to make it "internal".  If you want
   to learn more about use cases and improving the interface then
   make it non-"internal".  Users are best placed to tell you
   about both of those things.

   The function has been available for almost 3 years "internally".
   Do you really think more time to just ponder it "internally" is
   what is called for, to "discover the use cases and desirable
   interface"?

2. That "reason" applies to ALL new functions.  It's hardly a
   solid reason.  It's not a reason why _this_ function should
   be "internal".

3. The same (#2) applies to the only other reason given so far
   (by Stefan), which was that it is easier to make an existing
   function become non-"internal" than it is to make it become
   "internal".  That "reason" too applies to ALL new functions.

What would _you_ choose, to read an arbitrary Lisp expression
in the minibuffer?  Would you really choose the non-"internal"
function `read-minibuffer'?  Not if you wanted to help the
users whose input was being read.  Or would you use just
`read-from-minibuffer', passing `read-expression-map' and
`read-expression-history'?

(`read-expression-map' and `read-expression-history' have been
around since the beginning (Emacs 20, anyway), for reading sexps.)

Time to plant this little one outside, in the wide world beyond
the hothouse/incubator, I'd say.