What are the situations where defining a function as non-interactive is better than interactive?

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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.