Re: master a30781399b3: * subr-x (eval-command-interactive-spec): New function.

[Stefan Monnier]

>     * subr-x (eval-command-interactive-spec): New function.
[...]
> +;; FIXME: How about renaming this to just `eval-interactive-spec'?
> +;; It's not specific to the advice system.

Agreed.

> +(defun eval-command-interactive-spec (command)
> +  "Evaluate COMMAND's interactive form and return resultant list.
> +If COMMAND has no interactive form, return nil."
> +  (advice-eval-interactive-spec
> +   (cadr (or (and (symbolp command) (get command 'interactive-form))
> +             (interactive-form command)))))

Why the `get` business?  If we want that, it should be in
`interactive-form`, no (and AFAICT it is there, BTW)?
And why is that preferable over `(advice-)eval-interactive-spec`?

BTW, the reason I have not defined `eval-interactive-spec` (yet?)
is because it only provides an *approximation* of what
`call-interactively` would do.

The fundamental problem in `advice-eval-interactive-spec` is that

    (defun my-foo (..)
      (interactive (advice-eval-interactive-spec 'SPEC))
      ...)

will not behave 100% the same as

    (defun my-foo (..)
      (interactive SPEC)
      ...)

for example when SPEC contains "r", because of the `visargs/varies`
business in `call-interactively`.  The difference is that with "r", the
`command-history` will contain entries like

    (my-foo ... (point) (mark) ...)

whereas with `advice-eval-interactive-spec` they'll look like:

    (my-foo ... 457 562 ...)

I'm not completely sure how we should go about faithfully exporting
`callint.c` to ELisp in such a way that it can be (re)used in
interactive forms without losing such details.

One way would be to make `eval-interactive-spec` return a pair of
arglists: a list of values (to pass to `funcall-interactively`), and
a list of expressions (to store in `command-history`).  And then allow
interactive forms to return such pairs of arglists.

Another is to make it only return a list of expressions (and use
`mapcar #'eval` when we need to get the list of values from it), and
similarly let interactive forms return lists of expressions.  But since
currently interactive forms return lists of values, we'd need to somehow
add a marker to the returned lists to distinguish if we're returning
a list of values or a list of expressions.


        Stefan