Re: File modes facilities.

["Richard M. Stallman" <rms@gnu.org>]

    IMO, it is no less desireable than putting a defcustom for built-in
    variables or key bindings for built-in commands into a separate file.

The key bindings for primitive commands are mostly in the same file as
the commands: cmds.c.

As for cus-start.el, that is a kludge, and we keep forgetting to
update it.

    > If you want to put the code in a separate file, you can put
    > it in a function and make the interactive spec call that function.

    But this still has the MAJOR drawback that this will only apply to
    built-in functions that have already been instrumented to do that
    (which in practice means: none).

Right now, no primitive commands use Lisp to read their arguments.
Once we add a mechanism for them to to do so, we can start changing
some of these commands, one by one, to do so.

I want to keep the arg-reading code with the function definition,
not separate.

    My trivial changes provide a simple, efficient, flexible,
    user-extensible solution which can be applied to all existing
    functions and commands.

We don't want to apply it to very many.  And in the cases where we do,
it will be cleaner to keep the arg-reading code in the function
definition.

    But even for Lisp code, why copy all the code just to be able to
    change the way a command reads its arguments?

There is no need to copy the code.  You can simply call the original
function.

I do not like the idea of defining a different interactive spec
for an alias.  The alias should be equivalent to the original.
Likewise, I don't like the idea of being able to change a function's
interactive spec from a place remote from the function definition.