Re: custom-mode should not be interactive

[Stefan Monnier <monnier@iro.umontreal.ca>]

>     I'm not sure how to fix it though, as custom-mode is defined through
>     define-derived-mode, which always makes the mode function interactive.
>     One way is to define a new keyword argument for define-derived-mode.
>     What do you think?

> I think it would be better not to use `define-derived-mode'.
> In fact, `custom-mode' is not derived from another mode.


Of course, I disagree.
As the Elisp manual states:

      Even if the new mode is not an obvious derivative of any other mode,
   it is convenient to use `define-derived-mode' with a `nil' parent
   argument, since it automatically enforces the most important coding
   conventions for you.

As for the OP's question, the manual also states (23.2.2 Major Mode
Conventions):

   * Define a command whose name ends in `-mode', with no arguments,
     that switches to the new mode in the current buffer.  This command

so, it *should* be a "command", i.e. an interactive function.
The fact that it doesn't seem to do anything useful is not a problem.
As for the point number 2, we could address it by renaming the command to
customize-mode, although I'd just recommend partial-completion-mode
instead which helps just as well.


        Stefan