Re: Making a function than can only be used interactively

Re: Making a function than can only be used interactively

[Christopher Dimech]

> Jul 4, 2022, 20:45 by monnier@iro.umontreal.ca:

>>>>>            More seriously, what are you trying to gain by "mak[ing] a function
>>>>>            interactive only"?

>>>        For instance, writing an interactive wrapper function calling a non-interactive
>>>        mother function.


>    A common enough case, which you can do just fine without having to
>    prevent non-interactive calls to the interactive wrapper.

>>>        Technically, you can use `completing-read` and `read-from-minibuffer` if you'd also
>>>        like to set values interactively, while calling the function non-interactively.


>    You mean you can turn

>    (defun foo (a b c)
>    (interactive ...)
>    ...)

>    into

>    (defun foo ()
>    (interactive)
>    (let ((a ...)
>    (b ...)
>    (c ...))
>    ...))

Yes, that is what I had in mind.

>    Indeed. It's usually discouraged because it's incompatible with
>    non-interactive uses of the function, but in the case under discussion
>    you don't care about that because you already have another function to
>    use for non-interactive calls.

It is indeed incompatible with non-interactive use.  A thing that can be done
is fire the warning even when Lisp Code in not transformed into byte-code.

Although byte compilation in recommended, I wonder how often people actually
byte-compile every file.  Byte compiling will often tell you errors or warning
in your elisp code that you normally wouldn't know, but I think that running
an interactive-only function non-interactively is serious enough to insert the
warning in the warnings buffer anyway.


>>>        I am not sure if in practice that is ever desired.


>    It's done occasionally, typically in cases where it's difficult to
>    cleanly separate the part of the code that prompts the user from the
>    part that actually performs the desired operation.

>    Stefan

Re: Making a function than can only be used interactively

[Stefan Monnier]

>>    Indeed. It's usually discouraged because it's incompatible with
>>    non-interactive uses of the function, but in the case under discussion
>>    you don't care about that because you already have another function to
>>    use for non-interactive calls.
> It is indeed incompatible with non-interactive use.  A thing that can be done
> is fire the warning even when Lisp Code in not transformed into byte-code.

You could emit the warning/error during macro-expansion, indeed.
Something like:

    (defun foo (a b c)
      (interactive ...)
      (declare (compiler-macro (lambda (_) (error "Called non-interactively"))))
      ...)

Not sure what's the benefit, still.

> Although byte compilation in recommended, I wonder how often people actually
> byte-compile every file.

`flymake-mode` will run the compiler for you to get those warnings right
while you're writing the code.  If people don't see the warning because
they don't compile their files, then let's fix it by trying to convince
them to compile their files, which will come with a lot of other benefits.

> Byte compiling will often tell you errors or warning in your elisp
> code that you normally wouldn't know, but I think that running an
> interactive-only function non-interactively is serious enough to
> insert the warning in the warnings buffer anyway.

Usually calling an interactive-only function non-interactively is not
serious *at all* and very often it's The Right Thing to do.


        Stefan

Re: Making a function than can only be used interactively

[Christopher Dimech]

> Sent: Tuesday, July 05, 2022 at 9:45 AM
> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: tsdh@gnu.org, help-gnu-emacs@gnu.org
> Subject: Re: Making a function than can only be used interactively
>
> >>    Indeed. It's usually discouraged because it's incompatible with
> >>    non-interactive uses of the function, but in the case under discussion
> >>    you don't care about that because you already have another function to
> >>    use for non-interactive calls.
> > It is indeed incompatible with non-interactive use.  A thing that can be done
> > is fire the warning even when Lisp Code in not transformed into byte-code.
>
> You could emit the warning/error during macro-expansion, indeed.
> Something like:
>
>     (defun foo (a b c)
>       (interactive ...)
>       (declare (compiler-macro (lambda (_) (error "Called non-interactively"))))
>       ...)
>
> Not sure what's the benefit, still.
>
> > Although byte compilation in recommended, I wonder how often people actually
> > byte-compile every file.
>
> `flymake-mode` will run the compiler for you to get those warnings right
> while you're writing the code.  If people don't see the warning because
> they don't compile their files, then let's fix it by trying to convince
> them to compile their files, which will come with a lot of other benefits.
>
> > Byte compiling will often tell you errors or warning in your elisp
> > code that you normally wouldn't know, but I think that running an
> > interactive-only function non-interactively is serious enough to
> > insert the warning in the warnings buffer anyway.
>
> Usually calling an interactive-only function non-interactively is not
> serious *at all* and very often it's The Right Thing to do.
>
>         Stefan

Depends whether the person coding that function thinks it is.  What can he
do then?  Issue warning as you suggested with `declare`?

Re: Making a function than can only be used interactively

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Depends whether the person coding that function thinks it is.
> What can he do then?  Issue warning as you suggested with `declare`?

I don't think we can answer this in the abstract.  So, we'd first need
to have some concrete scenario before we can start discussing it.


        Stefan

RE: [External] : Re: Making a function than can only be used interactively

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

> > Depends whether the person coding that function thinks it is.
> > What can he do then?  Issue warning as you suggested with `declare`?
> 
> I don't think we can answer this in the abstract.  So, we'd first need
> to have some concrete scenario before we can start discussing it.

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

I've only browsed the thread, so apologies if some
actual problem (and its "why") has been specified.
From just perusing, I haven't noticed any.

As I guessed before, I'm still guessing (so far):

   there's an X-Y problem under the covers here
   somewhere...)

What is it that OP is _really_ trying to do/solve?

I'm guessing that's behind an inability by folks
who've coded zillions of functions to understand
what's being asked/requested.  What's the problem?

https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14371 bytes --]

Re: RE: [External] : Making a function than can only be used interactively

[Christopher Dimech]

> Sent: Wednesday, July 06, 2022 at 2:02 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Stefan Monnier" <monnier@iro.umontreal.ca>
> Cc: "'Help-Gnu-Emacs (help-gnu-emacs@gnu.org)'" <help-gnu-emacs@gnu.org>
> Subject: RE: [External] : Re: Making a function than can only be used interactively
>
> > > Depends whether the person coding that function thinks it is.
> > > What can he do then?  Issue warning as you suggested with `declare`?
> >
> > I don't think we can answer this in the abstract.  So, we'd first need
> > to have some concrete scenario before we can start discussing it.
>
> Yup.  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.

One thing that has been discussed is the following

(defun foo ()
(interactive)
(let ((a ...)
(b ...)
(c ...))
...))

RE: RE: [External] : Making a function than can only be used interactively

[Drew Adams]

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

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.

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

FW: RE: RE: [External] : Making a function than can only be used interactively

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

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 #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 15644 bytes --]

Re: FW: RE: RE: [External] : Making a function than can only be used interactively

[Christopher Dimech]

> Sent: Wednesday, July 06, 2022 at 10:40 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "'Help-Gnu-Emacs (help-gnu-emacs@gnu.org)'" <help-gnu-emacs@gnu.org>
> Cc: "Christopher Dimech" <dimech@gmx.com>
> Subject: FW: RE: RE: [External] :  Making a function than can only be used interactively
>
> I guess this was maybe intended for the help list?

It was.  Thanks.

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

Re: Making a function than can only be used interactively

[Christopher Dimech]

> Sent: Tuesday, July 05, 2022 at 10:05 AM
> From: "Christopher Dimech" <dimech@gmx.com>
> To: "Stefan Monnier" <monnier@iro.umontreal.ca>
> Cc: tsdh@gnu.org, help-gnu-emacs@gnu.org
> Subject: Re: Making a function than can only be used interactively
>
>
>
> > Sent: Tuesday, July 05, 2022 at 9:45 AM
> > From: "Stefan Monnier" <monnier@iro.umontreal.ca>
> > To: "Christopher Dimech" <dimech@gmx.com>
> > Cc: tsdh@gnu.org, help-gnu-emacs@gnu.org
> > Subject: Re: Making a function than can only be used interactively
> >
> > >>    Indeed. It's usually discouraged because it's incompatible with
> > >>    non-interactive uses of the function, but in the case under discussion
> > >>    you don't care about that because you already have another function to
> > >>    use for non-interactive calls.
> > > It is indeed incompatible with non-interactive use.  A thing that can be done
> > > is fire the warning even when Lisp Code in not transformed into byte-code.
> >
> > You could emit the warning/error during macro-expansion, indeed.
> > Something like:
> >
> >     (defun foo (a b c)
> >       (interactive ...)
> >       (declare (compiler-macro (lambda (_) (error "Called non-interactively"))))
> >       ...)
> >
> > Not sure what's the benefit, still.

I am not confident the declare command will always work.

Not for

(defun foo ()
(interactive)
(let ((a ...)
(b ...)
(c ...))
...))


> > > Although byte compilation in recommended, I wonder how often people actually
> > > byte-compile every file.
> >
> > `flymake-mode` will run the compiler for you to get those warnings right
> > while you're writing the code.  If people don't see the warning because
> > they don't compile their files, then let's fix it by trying to convince
> > them to compile their files, which will come with a lot of other benefits.
> >
> > > Byte compiling will often tell you errors or warning in your elisp
> > > code that you normally wouldn't know, but I think that running an
> > > interactive-only function non-interactively is serious enough to
> > > insert the warning in the warnings buffer anyway.
> >
> > Usually calling an interactive-only function non-interactively is not
> > serious *at all* and very often it's The Right Thing to do.
> >
> >         Stefan
>
> Depends whether the person coding that function thinks it is.  What can he
> do then?  Issue warning as you suggested with `declare`?
>
>