Re: Recent attempts at standardizing major mode definitions.

["Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>]

> What is the benefit of the current situation?  It uses a macro for a
> purpose that is way more general than its original intended purpose
> and artificially forces two functionalities into one.  It all seems
> very unnatural to me.

I don't just want a standard macro.  I want this macro to strongly
encourage a "standard" behavior so that users can expect things to
work consistently, so that macro has to (by default) do more than
the strict necessary, although it (of course) needs to be flexible
enough to allow those defaults to be overridden (which the current
`define-derived-mode' does allow although not always in the most
natural/convenient way).

Many authors forget to setup an abbrev-table.
Many authors forget to run hooks.
Other authors forget to run kill-all-local-variables.
Others don't use a `foo-mode-map' variable.
Yet others don't use a `foo-mode-syntax-table' variable.
Some authors don't notice that their mode should derive from text-mode.
Others do notice but derive the mode in incorrect ways (or at
least in inconsistent ways).
Most authors don't seem to realize that just like there is a text-mode
from which most text-like editing modes derive, there should be a prog-mode
from which most programming modes derive.
...

> Defining a separate define-major-mode in the way you suggest would be
> an improvement over the current situation.  However, it still seems
> unnatural to define a very general function essentially as a special
> case of an extremely specialized function.  It would be far more
> logical to do the opposite.

Sure.  Except that define-derived-mode would pretty much do the same
things as define-derived-mode and since define-derived-mode exists,
it seems a good idea to use it.  Especially since I truly think that
modes should derive much less often from nil than they currently do.
Take a look at the expansion of define-derived-mode when the
PARENT is nil.


	Stefan