bug#21465: [PATCH] CC-modes hierarchy

[Alan Mackenzie <acm@muc.de>]

In article <mailman.971.1442025193.19560.bug-gnu-emacs@gnu.org> you wrote:
> Package: Emacs
> Version: 25.0.50


> Any objection to the patch below?

> It does the following:
> - Move code common to all CC-mode major modes to a c-mode-common-mode function.
> - Add new c-derivative-mode as a parent of C, C++, and ObjC, for
>   settings which apply to C-derived languages but not for others.
>   This has become necessary given that CC-mode is used nowadays as an
>   engine for modes which have little to do with C.
> - Remove code that's redundant with what define-derived-mode does:
>   - set local-map
>   - set syntax-table
>   - set keymap parent
> - Remove c-make-inherited-keymap, since it's not used any more.
> - Fix c-after-font-lock-init so it only *moves* the function, and doesn't
>   accidentally add it (in case the derived mode decided to remove the function
>   from the hook, for example).

Why?  What is the point of the change?  It introduces an extra layer onto
the stack of major modes, but this extra layer seems to do no more than
execute two forms, `(c-initialize-cc-mode t)' and `(setq abbrev-mode t)'.
There is no coherence here, just two forms which happen to be in several
mode's initialisation routines and put together, even though they don't
form a coherent whole.  If this is to be done, surely a defun rather than
an extra layer of moding would be better.

c-derivative-mode would really need to be called c-c-derivative mode to
avoid confusion, since the prefix "c-" is just a name prefix.  But again,
what's this mode for?  It does nothing other than add a single binding to
a newly created key map.  I'm not convinced there's any need to be able to
treat the "C derivative" languages differently from all the others - 
anything you'd do in C++ Mode, you'd also be wanting to do in Java Mode
in the (somewhat unusual) circumstance that you're hacking both languages.
There's `c-mode-common-hook' for this.  Occasionally, people ask which
hook they should make their changes in.  The standard recommendation is
in `c-mode-common-hook' apart from (rare) things which are specific to
just one language.  If there are one or two extra levels of mode hook,
there will be extra confusion.

These new modes would add all the complexity of key maps, mode hooks, and
whatever, yet not achieve any coherent abstraction.  They would fragment
the initialisation code.  (Not that the current initialisation code is
anything to write home about, but this rearrangement wouldn't be an
improvement.)

c-after-font-lock-init surely isn't broken.  c-after-change is ALWAYS on
after-change-functions.  Without it, CC Mode simply wouldn't function.  Or
is there some way that Font Lock is called before CC Mode's
initialisation, and c-after-change is somehow sneeking onto the hook
twice?  Or something like that.

There is probably scope for getting rid of the explicit settings of the
local key map, syntax table, and so on.

> AFAIK this patch has no issues w.r.t compatibility since it relies on
> behavior of define-derived-mode which has existed since "for ever".
> But it hasn't seen much testing, admittedly (except for my own personal use).

The question is, will XEmacs's define-derived-mode work?

By the way, abbrev mode is used to expand "else" and "while" to themselves
+ re-indentation.  There are one or two other keywords handled likewise.
This isn't something either of us like, but doesn't seem urgent enough
to get round to fixing.

>         Stefan

[ patch read and snipped. ]

-- 
Alan Mackenzie (Nuremberg, Germany).