Re: Emacs design question (was: run-mode-hooks)

[Richard Stallman <rms@gnu.org>]

    >From time to time I have found that you are opposed to introducing
    (mandatory use of) additional abstraction levels.

Yes, I am reluctant to do this, because in my experience that approach
to software design quickly makes simple problems complex.  That is why,
for example, in Emacs we generally have primitive data types only
for jobs that couldn't possibly be done without one (because the C
code has to handle them specially).

I don't make this an absolute rule, because sometimes it is worth
adding a new data type or a new abstraction level.  But I'd rather
be slow to do this than quick to do this.

    In this case, you are suggesting that existing major modes continue
    to do things "manually", rather than to use the new abstraction.
    >From the past, I remember something similar about define-minor-mode
    or define-derived-mode: there was a change to convert a mode to one
    of them, and you reversed that change.

That is a completely different kind of issue. I objected to use of
define-derived-mode for a mode that was not derived.  I think that
contradicts what the name says.

I wouldn't object to defining a new define-major-mode construct and
using it for that mode.  I think it would be good to do this.
I don't want to make use of define-major-mode "mandatory" because
there are plenty of mode definitions that are not in our files, and
we can't change them all to use define-major-mode.

That being true, I don't see a reason to change all the modes in the
Emacs sources either.  However, it would be ok to change the ones
you feel like changing.