I guess this was maybe intended for the help list?

-----Original Message-----
From: Christopher Dimech <dimech@gmx.com> 
Sent: Tuesday, July 5, 2022 2:15 PM
To: Drew Adams <drew.adams@oracle.com>
>
> > > Has any concrete description been presented
> > > in this thread that makes clear what the real
> > > problem to be solved is - the use case behind
> > > the question?
> >
> > The filling of arguments could be difficult
> > if a sequence of interactive prompt depend
> > on previous values.
>
> Hard to guess what you mean.  Example?
>
> What's to prevent someone from calling the
> function (whatever it is) with appropriate
> arguments, whether or not some of them depend
> on others?
>
> > One thing that has been discussed is the following
> > (defun foo ()
> >  (interactive)
> >  (let ((a ...)
> >        (b ...)
> >        (c ...))
> >   ...))
>
> Didn't Stefan show that only to indicate that
> you can prompt for values in the body of a
> function, instead of (or in addition to) doing
> so in an `interactive' spec?

Yes.  That strategy could easily make a function inappropriate
for non-interactive use.  The result would not necessarily be
a result of bad design.

> IOW, presumably he was suggesting that some of
> the "..." to provide values for a, b, and c
> could come from prompting a user - IOW, making
> the function interactive regardless of how
> it's called.
>
> I don't see what that has to do with any
> problem of "filling arguments" when calling
> from Lisp.
>
> Sorry, but so far I'm not grasping what the
> problem is - what OP is really trying to do.

The OP wants to make the function purely interactive.
But at a low-level, you can't have a function that
can be called interactively and not non-interactively.

The sensible way out is for the OP to include its inappropriateness
for use in elisp code in the documentation.  Either that, or using
a specific part-name separated by "--" for the function name, as
indicator that function is inappropriate for elisp code.  Emacs
has done this strategy before.

> But again, I only skimmed the thread.  If you
> think the question / use case is clear to
> others then please ignore my feedback.

Although I understand it, the result would either be unreliable or
too cumbersome for actual use.