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

[Michael Heerdegen]

Stefan Monnier <address@hidden> writes:

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

This seems a bit like a pseudo problem to me.  The difficulty to define
and distinguish the two cases indicates that.

We also don't have two emacs lisp modes.  Emacs Lisp mode doesn't turn
off completion for the sub-s-exps of a s-exp that are not expressions.
We try to provide a context dependent behavior as good as we can.  If I
want to write random data, I just don't use completion, simply because
it's not useful.

Personally I use emacs-lisp-mode in all minibuffers that prompt for an
elisp-whatever.  Apart from completion, some other familiar keys are
useful as well.  And font locking, paredit, rainbow-delimiters...

And I'm not sure how large the part of corner cases is.  Like this one:
In el-search.el, I prompt for a pcase pattern.  These are typically not
expressions, but it is useful to have completion there.  Completion is
not useful at every position, but that's not the case for expressions as
well (well, they can contain pcase patterns...).

Apart from that, I would say, let's wait with concepts like "whether a
s-exp is an expression or not is undefined until you try to evaluate it"
until we have quantum computers :-)


Regards,

Michael.