Re: Recent attempts at standardizing major mode definitions.

[Luc Teirlinck]

Stefan Monnier wrote:

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

Yes, but the question is, do we allow them to override by choosing a
more general function or do we force them to use "tricks".  The former
is not only much more convenient for the author, it also avoids the
extremely real possibility of those "tricks" introducing bugs and
unintended side effects.  Overriding with a separate function seems
much more natural.  We get two functions: 

1. define-derived-mode, to be used if either the author is not sure
which values to plug in for the arguments of define-major-mode or if
the new mode is a "true" derived mode.

2. A more general function define-major-mode, if the author needs more
flexibility.



   Many authors forget to setup an abbrev-table.

define-major-mode will have an abbrev-table argument.  End of problem.
The author can explicitly choose not to have an abbrev-table, but
(s)he can not do it without thinking.

   Many authors forget to run hooks.

define-major-mode will run the standard mode-hook as the very last
thing it does.

   Other authors forget to run kill-all-local-variables.

define-major-mode will call that function just as define-derived-mode
does.

   Others don't use a `foo-mode-map' variable.

Either this will be set automatically or the author will have to
explicitly ask for this not to be done.

   Yet others don't use a `foo-mode-syntax-table' variable.

Will only work if the author explicitly asks not to use it.

   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.

define-derived-mode does not solve that problem.  The author still
has to choose the parent mode and that choice could be stupid.

define-major-mode will have more arguments than define-derived-mode
does and forces the author to worry about all kinds of stuff.  If
(s)he does not need flexibility, (s)he will choose
define-derived-mode.  We could, and maybe should, have the two
documentation strings refer to each other, thus making sure that the
author knows that (s)he has a less complex (more flexible,
respectively) function available.

   Take a look at the expansion of define-derived-mode when the
   PARENT is nil.

I did.  As I pointed out, the piece of code I sent was essentially an
adaptation of that expansion.  It was just a rough draft, however.  It
needs to be changed to take care of Richard's remarks and problems I
myself discovered in the meantime.  Of course, it could also be
changed to take care of any objections you have.  Remember though that
define-major-mode is intended for knowledgeable authors and should
work for a-typical modes.

Sincerely,

Luc.