[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making a function than can only be used interactively

From: Christopher Dimech
Subject: Re: Making a function than can only be used interactively
Date: Mon, 4 Jul 2022 23:07:28 +0200

> Jul 4, 2022, 20:45 by

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]