Re: Reify the cc-mode-common into an actual parent mode

[Stefan Monnier]

> The canonical way to create a mode derived from CC Mode is to derive
> from, say, `c-mode', call `c-add-language', then specify the values of
> the language variables which differ from those of `c-mode'.

Hmm... you don't seem to preach by example here: none of CC-mode's
predefined modes inherit from another.  So I'm not sure "canonical" is
the appropriate word.

I also looked at some of the externally maintained major modes that rely
on CC-mode, and they generally don't seem to derive from any of your
predefined modes either.

> There's nothing coherent about `c-mode-common'; it isn't sensible to set
> a buffer to this mode, and it would be erroneous to attempt to derive a
> mode (other than the seven within CC Mode) directly from it, since the
> language variables for the new mode wouldn't get initialised.

Currently all CC modes seem to either derive from prog-mode or from
fundamental-mode, so they all have the same need to explicitly call
things like (c-init-language-vars-for <mymode>).  Using c-mode-common
doesn't make any difference in this respect.

> modes that have them.  It so happens that, at the moment, those two
> functions don't affect `c-update-modeline', so things work, but this
> executing in the wrong order is storing up trouble for the future, should
> some form in `c-mode''s :after-hook position need executing before
> `c-update-modeline'.

The fact that they don't interfere is not an accident, IMO.
[ BTW, I notice that define-derived-mode doesn't document the relative
  order of execution of inherited :after-hooks.  It's probably better
  that way, admittedly.  ]


        Stefan