Re: Making a function than can only be used interactively

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Another debate is that although one can declare a non-interactive function,
> and an interactive function that can run non-interactively; there is no
> construct that can define a purely interactive function.

That's because an "interactive function" is just a normal function
together with some auxiliary info to tell `call-interactive` how to call
it "interactively".  Internally `call-interactively` will end up calling
the function via `funcall`, i.e. "non-interactively".  So at
a low-level, technically you just can't have a function that can be
called interactively and not non-interactively.  You can try and kludge
it up above if you really want to (like we've seen in a few different
ways), but we're back to the question: what's the benefit?

> Does a function know whether it was run from lisp code or from the user in
> an Emacs session?

Trying to behave differently depending on who/how a function was called
goes against the design principle of functions, so it tends to be kludgy
and unreliable, like `called-interactively-p`.

BTW, here's another way to make a function that "can't" be called
non-interactively:

    (defun foo (a b c &optional extra)
      (interactive
       (list ... 'dont-you-dare-call-me-non-interactively))
      (unless (eql extra 'dont-you-dare-call-me-non-interactively)
        (error "foo called non-interactively"))
      ...)

You can make it "more robust" with something like:

    (defalias 'foo
      (let ((witness (make-symbol "dont-you-dare-call-me-non-interactively")))
        (lambda (a b c &optional extra)
          (interactive
            (list ... witness))
          (unless (eql extra witness)
            (error "foo called non-interactively"))
          ...)))

But again: is it really worth the trouble?  What is there to gain?
Instead of beating the undesired callers with a stick, why not try and
convince them to do something else with  carrot?


        Stefan