4

Assume that we have a function which can be defined either interactive or non-interactive. When we define it as interactive, we can use it as a command by invoking M-x so we have more freedom.

I am wondering what are the situations where defining a function as non-interactive has some advantages over the interactive method.

  • 2
    Some functions are steps in a chain of functions -- those would not make any sense to be made interactive. E.g., function 3-of-5 creates a buffer and sets up a major-mode -- 1-of-5 is interactive because that is what the author decided a user should launch to start the process -- 2of5 gathers the data to be inserted into the buffer that has not yet been created -- 4of5 inserts the data and does some other stuff -- 5of5 puts the finishing touches (e.g., overlays) and then displays the buffer in the proper window/frame. So, as you can see, only 1of5 should be interactive. – lawlist Jul 25 '15 at 19:09
8

While it is entirely subjective, I would suggest only making functions interactive if you actually expect them to be called that way. Many functions are intended to be used as building blocks rather than end-user commands.

It can be simpler to define a non-interactive function. While these factors are important for any function, they are particularly important for interactive commands:

  • Is it fully documented?
  • If it takes arguments, does it provide helpful prompts and defaults?
  • Does it have a meaningful / unique name? Consider that commands are often picked from a list of completion candidates.
  • How does it handle prefix arguments?

(Also note that non-interactive functions can always be called with M-:.)

7

Others have mentioned some reasons for not making a given function into a command. Here is another: user discovery and access to commands.

If you ever manipulate or access commands interactively by name (e.g. M-x, C-h a).

(Or if you ever manipulate them by program, then you typically want them distinguished from other functions. But you might argue that this case is a side effect of the existing separation into two camps.)

As an example of why you might not want the two to be confused: Try C-u C-h a ^save RET. About half of the functions listed are commands. If all of them were commands then they would all be candidates when you did M-x save TAB.

4

When you're writing Emacs Lisp code, or indeed any sort of code, one of the most important things is to divide your work clearly, so users and programmers both can see role of every function.

Interactive functions or commands are supposed to be invoked by user directly. They allow to use functionality you want to provide. You should not declare interactive functions that are not supposed to be user interface of your package, this is confusing and not only because of "contamination" of list of available commands in M-x for example, but on design level, which is more important.

Similarly, you could ask why Emacs Lisp programmers use this sort of convention: <package-name>-<symbol> for public functions and <package-name>--<symbol> for auxiliary, internal ones. Again, this helps to divide your program and make clearer purpose of every element.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.