Re: Recent attempts at standardizing major mode definitions.

[Stefan Monnier]

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

There are other alternatives than tricks.

> the new mode is a "true" derived mode.

What's a "true" derived mode ?
Is latex-mode a true derived mode of text-mode ?
Should c-mode be a true derived mode of prog-mode ?
Should dired-mode be a true derived mode of list-mode ?

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

Are you saying that if we have

        (defalias 'define-major-mode 'define-derived-mode)

we can't make define-major-mode more flexible ?
I definitely think define-derived-mode should be more flexible
and intend to do exactly that, using keyword arguments.

>    Many authors forget to setup an abbrev-table.
> 
> define-major-mode will have an abbrev-table argument.

Oh so now, you macro will have umpteen arguments ?
Why not use CL-style keyword arguments instead ?
Then your calling-convention will be more friendly and compatible
with the current define-derived-mode calling convention.

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

Sounds like define-derived-mode can (and clumsily does) behave
exactly like that already.  I don't think the clumsiness is a big
problem, since it's extremely rare to have a major mode that
shouldn't have its own keymap.  I actually can't think of any
case right now.

>    Yet others don't use a `foo-mode-syntax-table' variable.
> Will only work if the author explicitly asks not to use it.

Again, define-derived-mode behaves just like what you describe.

>    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 problem is that I think we should have more structure and sharing
between modes and that if we fix that, then 99% of the modes will
derive from some other.  That's why I think it's not even worthwhile
to define `define-major-mode' as an alias for `define-derived-mode'.

> define-major-mode will have more arguments than define-derived-mode
> does and forces the author to worry about all kinds of stuff.

Why would you want to impose such a burden on the programmer when
there are perfectly fine defaults available ?

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

And you noticed that it's pretty much exactly the same as what you
suggested, so what's the point of your separate function ?

> define-major-mode is intended for knowledgeable authors and should
> work for a-typical modes.

Can you give me examples of atypical modes ?
I know about special modes such as dired/help/... but AFAIK, the only
"problem" with using define-derived-mode for them is that it uselessly
creates an abbrev-table which you can't use unless you first make the
buffer read-write.


        Stefan