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

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

I wasn't as clear as I should have been. 

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

Your analogy is OK.  I wouldn't speak of an "Elisp expression" here,
since to me that just means any expression - sexp that you can
construct with Emacs Lisp.  But now I know what you mean.  It's not
about any intention to evaluate; your speaking of that was throwing
me off.

I was really asking only about getting the extra hyphen removed
from `read--expression'. ;-)  Use cases I have for it do involve
sometimes immediately evaluating the sexp read, but sometimes they
involve putting such sexps together to form larger sexps (which
sometimes might be evaluated at some point).

I don't have a problem with the completion that `read-expression'
provides, and in many such use cases the names to complete are
indeed names of program parts - in particular names of functions
and variables.  This, in spite of the fact that the sexps read
need not be evaluable without error.

For more general sexps - your XML (S-exp) level of generality,
there is completion against an obarray.  And in some intermediate
cases `dabbrev' completion (names from one or more buffers) can
be helpful.  When Elisp buffers are involved, it too can be about
reading bits of potential code.

In this thread I was really only talking about `read--expression'
and what it does.  What it does is useful also to ordinary Emacs
user-programmers, not just "internally".

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

See above.  Any Lisp sexp can be related to Elisp code.  Any data
can be a piece of some code.  But yes, I was interested here in
what `read--expression' does already.

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

It's what Davis was trying to distinguish `read--expression' as:
reading an expression "intended for evaluation" (paraphrasing).
Likewise, you.  You both tried to distinguish what it does as
reading an expression that might be evaluated (even though it can
also read expressions that cannot, without raising an error).

Creating variants of the behavior was his idea.  I'm fine with
the current behavior (which I don't associate directly with
evaluation, but which I recognize provides completion against
known functions and variables).

> `read--expression' already couldn't care less whether you'll
> pass the result to `eval' or not.

Thank you.  That's what I was saying.  It is you (and Davis) who
used "evaluation" to characterize it.

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

Even that assumption is too strong (see above), but I don't know a
great way to characterize it.  I'd say that the completion against
existing function (after `(' ) and variable names sums it up, but
I don't have a name for that.  "Expression" doesn't say more than
"sexp", to me - it's just as general.

> > 1. That's not a good reason to make it "internal".
> 
> I already said that it's internal for no particular reason.

Not really.  You said that it's internal because it's easier to
later make a name non-internal than the reverse.  Which is true,
but which is not a great reason, in itself: it would apply to
every new function.

I submitted bug report #24386 to get rid of the "internal"
characterization.