[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: RE: RE: [External] : Making a function than can only be used intera
From: |
Drew Adams |
Subject: |
FW: RE: RE: [External] : Making a function than can only be used interactively |
Date: |
Tue, 5 Jul 2022 22:40:43 +0000 |
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.
<<attachment: winmail.dat>>
- Re: Making a function than can only be used interactively, (continued)
Re: Making a function than can only be used interactively, Christopher Dimech, 2022/07/04
- Re: Making a function than can only be used interactively, Stefan Monnier, 2022/07/04
- Re: Making a function than can only be used interactively, Christopher Dimech, 2022/07/04
- Re: Making a function than can only be used interactively, Stefan Monnier, 2022/07/04
- RE: [External] : Re: Making a function than can only be used interactively, Drew Adams, 2022/07/05
- Re: RE: [External] : Making a function than can only be used interactively, Christopher Dimech, 2022/07/05
- RE: RE: [External] : Making a function than can only be used interactively, Drew Adams, 2022/07/05
- Message not available
- FW: RE: RE: [External] : Making a function than can only be used interactively,
Drew Adams <=
- Re: FW: RE: RE: [External] : Making a function than can only be used interactively, Christopher Dimech, 2022/07/05
Re: Making a function than can only be used interactively, Christopher Dimech, 2022/07/04
Re: Making a function than can only be used interactively, Christopher Dimech, 2022/07/04