bug#21465: [PATCH] CC-modes hierarchy

bug#21465: [PATCH] CC-modes hierarchy

[Stefan Monnier]

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

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


        Stefan


diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
index 97491e4..4279c9f 100644
--- a/lisp/progmodes/cc-mode.el
+++ b/lisp/progmodes/cc-mode.el
@@ -71,6 +71,17 @@
 ;;
 ;;    http://lists.sourceforge.net/mailman/listinfo/cc-mode-announce
 
+;; Externally maintained major modes which use CC-mode's engine:
+;; - cuda-mode
+;; - haxe-mode
+;; - d-mode
+;; - dart-mode
+;; - cc-php-js-cs.el
+;; - php-mode
+;; - yang-mode
+;; - math-mode (mathematica)
+;; - unrealscript-mode
+
 ;;; Code:
 
 ;; For Emacs < 22.2.
@@ -200,22 +211,6 @@ control).  See \"cc-mode.el\" for more info."
 (defvar c-mode-base-map ()
   "Keymap shared by all CC Mode related modes.")
 
-(defun c-make-inherited-keymap ()
-  (let ((map (make-sparse-keymap)))
-    ;; Necessary to use `cc-bytecomp-fboundp' below since this
-    ;; function is called from top-level forms that are evaluated
-    ;; while cc-bytecomp is active when one does M-x eval-buffer.
-    (cond
-     ;; Emacs
-     ((cc-bytecomp-fboundp 'set-keymap-parent)
-      (set-keymap-parent map c-mode-base-map))
-     ;; XEmacs
-     ((fboundp 'set-keymap-parents)
-      (set-keymap-parents map c-mode-base-map))
-     ;; incompatible
-     (t (error "CC Mode is incompatible with this version of Emacs")))
-    map))
-
 (defun c-define-abbrev-table (name defs &optional doc)
   ;; Compatibility wrapper for `define-abbrev' which passes a non-nil
   ;; sixth argument for SYSTEM-FLAG in emacsen that support it
@@ -1219,7 +1214,7 @@ Note that the style variables are always made local to the buffer."
       (backward-char))			; back over (, [, <.
     (and (/= new-pos pos) new-pos)))
 
-(defun c-change-expand-fl-region (beg end old-len)
+(defun c-change-expand-fl-region (_beg _end _old-len)
   ;; Expand the region (c-new-BEG c-new-END) to an after-change font-lock
   ;; region.  This will usually be the smallest sequence of whole lines
   ;; containing `c-new-BEG' and `c-new-END', but if `c-new-BEG' is in a
@@ -1307,8 +1302,9 @@ Note that the style variables are always made local to the buffer."
 (defun c-after-font-lock-init ()
   ;; Put on `font-lock-mode-hook'.  This function ensures our after-change
   ;; function will get executed before the font-lock one.
-  (remove-hook 'after-change-functions 'c-after-change t)
-  (add-hook 'after-change-functions 'c-after-change nil t))
+  (when (memq #'c-after-change after-change-functions)
+    (remove-hook 'after-change-functions #'c-after-change t)
+    (add-hook 'after-change-functions #'c-after-change nil t)))
 
 (defun c-font-lock-init ()
   "Set up the font-lock variables for using the font-lock support in CC Mode.
@@ -1401,6 +1397,27 @@ This function is called from `c-common-init', once per mode initialization."
     (c-update-modeline)))
 
 \f
+(defvar c-mode-common-map c-mode-base-map)
+
+(define-derived-mode c-mode-common prog-mode "CC-generic"
+  "Pseudo major mode, parent of all modes using the CC engine."
+  (c-initialize-cc-mode t)
+  (setq abbrev-mode t))                  ;FIXME: Why?
+
+(defvar c-derivative-mode-map
+  ;; FIXME: We can't have the menu on this keymap, because the menus for C,
+  ;; C++, and ObjC can't be shared: the only difference between them is their
+  ;; title, but easy-menu offers no way to compute the title dynamically.
+  (let ((map (make-sparse-keymap)))
+    ;; Add bindings which are useful for any C derivative.
+    (define-key map "\C-c\C-e"  #'c-macro-expand)
+    map)
+  "Keymap used in c-derivative-mode buffers.")
+
+(define-derived-mode c-derivative-mode c-mode-common "C-derivative"
+  "Pseudo major mode, parent of all modes for C derivatives.
+A C derivative is a language which is a superset of C (or is C itself).")
+
 ;; Support for C
 
 (defvar c-mode-syntax-table
@@ -1413,9 +1430,8 @@ This function is called from `c-common-init', once per mode initialization."
   "Abbreviation table used in c-mode buffers.")
 
 (defvar c-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for C.
-    (define-key map "\C-c\C-e"  'c-macro-expand)
     map)
   "Keymap used in c-mode buffers.")
 
@@ -1454,7 +1470,7 @@ This function is called from `c-common-init', once per mode initialization."
 (unless (fboundp 'prog-mode) (defalias 'prog-mode 'fundamental-mode))
 
 ;;;###autoload
-(define-derived-mode c-mode prog-mode "C"
+(define-derived-mode c-mode c-derivative-mode "C"
   "Major mode for editing K&R and ANSI C code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from a
 c-mode buffer.  This automatically sets up a mail buffer with version
@@ -1468,11 +1484,6 @@ initialization, then `c-mode-hook'.
 
 Key bindings:
 \\{c-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table c-mode-syntax-table)
-  (setq local-abbrev-table c-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map c-mode-map)
   (c-init-language-vars-for 'c-mode)
   (c-make-macro-with-semi-re) ; matches macro names whose expansion ends with ;
   (c-common-init 'c-mode)
@@ -1495,9 +1506,8 @@ Key bindings:
   "Abbreviation table used in c++-mode buffers.")
 
 (defvar c++-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for C++.
-    (define-key map "\C-c\C-e" 'c-macro-expand)
     (define-key map "\C-c:"    'c-scope-operator)
     (define-key map "<"        'c-electric-lt-gt)
     (define-key map ">"        'c-electric-lt-gt)
@@ -1508,7 +1518,7 @@ Key bindings:
 		  (cons "C++" (c-lang-const c-mode-menu c++)))
 
 ;;;###autoload
-(define-derived-mode c++-mode prog-mode "C++"
+(define-derived-mode c++-mode c-derivative-mode "C++"
   "Major mode for editing C++ code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from a
 c++-mode buffer.  This automatically sets up a mail buffer with
@@ -1523,11 +1533,6 @@ initialization, then `c++-mode-hook'.
 
 Key bindings:
 \\{c++-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table c++-mode-syntax-table)
-  (setq local-abbrev-table c++-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map c++-mode-map)
   (c-init-language-vars-for 'c++-mode)
   (c-make-macro-with-semi-re) ; matches macro names whose expansion ends with ;
   (c-common-init 'c++-mode)
@@ -1549,9 +1554,8 @@ Key bindings:
   "Abbreviation table used in objc-mode buffers.")
 
 (defvar objc-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for Objective-C.
-    (define-key map "\C-c\C-e" 'c-macro-expand)
     map)
   "Keymap used in objc-mode buffers.")
 
@@ -1561,7 +1565,7 @@ Key bindings:
 ;;;###autoload (add-to-list 'auto-mode-alist '("\\.m\\'" . objc-mode))
 
 ;;;###autoload
-(define-derived-mode objc-mode prog-mode "ObjC"
+(define-derived-mode objc-mode c-derivative-mode "ObjC"
   "Major mode for editing Objective C code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from an
 objc-mode buffer.  This automatically sets up a mail buffer with
@@ -1576,11 +1580,6 @@ initialization, then `objc-mode-hook'.
 
 Key bindings:
 \\{objc-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table objc-mode-syntax-table)
-  (setq local-abbrev-table objc-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map objc-mode-map)
   (c-init-language-vars-for 'objc-mode)
   (c-make-macro-with-semi-re) ; matches macro names whose expansion ends with ;
   (c-common-init 'objc-mode)
@@ -1604,7 +1603,7 @@ Key bindings:
   "Abbreviation table used in java-mode buffers.")
 
 (defvar java-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for Java.
     map)
   "Keymap used in java-mode buffers.")
@@ -1622,7 +1621,7 @@ Key bindings:
 ;;;###autoload (add-to-list 'auto-mode-alist '("\\.java\\'" . java-mode))
 
 ;;;###autoload
-(define-derived-mode java-mode prog-mode "Java"
+(define-derived-mode java-mode c-mode-common "Java"
   "Major mode for editing Java code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from a
 java-mode buffer.  This automatically sets up a mail buffer with
@@ -1637,11 +1636,6 @@ initialization, then `java-mode-hook'.
 
 Key bindings:
 \\{java-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table java-mode-syntax-table)
-  (setq local-abbrev-table java-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map java-mode-map)
   (c-init-language-vars-for 'java-mode)
   (c-common-init 'java-mode)
   (easy-menu-add c-java-menu)
@@ -1660,7 +1654,7 @@ Key bindings:
   "Abbreviation table used in idl-mode buffers.")
 
 (defvar idl-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for IDL.
     map)
   "Keymap used in idl-mode buffers.")
@@ -1671,7 +1665,7 @@ Key bindings:
 ;;;###autoload (add-to-list 'auto-mode-alist '("\\.idl\\'" . idl-mode))
 
 ;;;###autoload
-(define-derived-mode idl-mode prog-mode "IDL"
+(define-derived-mode idl-mode c-mode-common "IDL"
   "Major mode for editing CORBA's IDL, PSDL and CIDL code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from an
 idl-mode buffer.  This automatically sets up a mail buffer with
@@ -1686,10 +1680,7 @@ initialization, then `idl-mode-hook'.
 
 Key bindings:
 \\{idl-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table idl-mode-syntax-table)
-  (setq local-abbrev-table idl-mode-abbrev-table)
-  (use-local-map idl-mode-map)
+  (kill-local-variable 'abbrev-mode) ;FIXME: Only mode that doesn't enable it!?
   (c-init-language-vars-for 'idl-mode)
   (c-common-init 'idl-mode)
   (easy-menu-add c-idl-menu)
@@ -1710,7 +1701,7 @@ Key bindings:
   "Abbreviation table used in pike-mode buffers.")
 
 (defvar pike-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Additional bindings.
     (define-key map "\C-c\C-e" 'c-macro-expand)
     map)
@@ -1723,7 +1714,7 @@ Key bindings:
 ;;;###autoload (add-to-list 'interpreter-mode-alist '("pike" . pike-mode))
 
 ;;;###autoload
-(define-derived-mode pike-mode prog-mode "Pike"
+(define-derived-mode pike-mode c-mode-common "Pike"
   "Major mode for editing Pike code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from a
 pike-mode buffer.  This automatically sets up a mail buffer with
@@ -1738,11 +1729,6 @@ initialization, then `pike-mode-hook'.
 
 Key bindings:
 \\{pike-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table pike-mode-syntax-table)
-  (setq local-abbrev-table pike-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map pike-mode-map)
   (c-init-language-vars-for 'pike-mode)
   (c-common-init 'pike-mode)
   (easy-menu-add c-pike-menu)
@@ -1765,11 +1751,11 @@ Key bindings:
   "Abbreviation table used in awk-mode buffers.")
 
 (defvar awk-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for awk.
-    (define-key map "#" 'self-insert-command)
-    (define-key map "/" 'self-insert-command)
-    (define-key map "*" 'self-insert-command)
+    (define-key map "#" 'self-insert-command);Override electric parent binding.
+    (define-key map "/" 'self-insert-command);Override electric parent binding.
+    (define-key map "*" 'self-insert-command);Override electric parent binding.
     (define-key map "\C-c\C-n" 'undefined) ; #if doesn't exist in awk.
     (define-key map "\C-c\C-p" 'undefined)
     (define-key map "\C-c\C-u" 'undefined)
@@ -1788,7 +1774,7 @@ Key bindings:
 (declare-function c-awk-unstick-NL-prop "cc-awk" ())
 
 ;;;###autoload
-(define-derived-mode awk-mode prog-mode "AWK"
+(define-derived-mode awk-mode c-mode-common "AWK"
   "Major mode for editing AWK code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from an
 awk-mode buffer.  This automatically sets up a mail buffer with version
@@ -1807,11 +1793,6 @@ Key bindings:
   ;; declared in cc-awk.el and hasn't yet been loaded.
   :syntax-table nil
   (require 'cc-awk)			; Added 2003/6/10.
-  (c-initialize-cc-mode t)
-  (set-syntax-table awk-mode-syntax-table)
-  (setq local-abbrev-table awk-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map awk-mode-map)
   (c-init-language-vars-for 'awk-mode)
   (c-common-init 'awk-mode)
   (c-awk-unstick-NL-prop)

bug#21465: [PATCH] CC-modes hierarchy

[Mark Oteiza]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Package: Emacs
> Version: 25.0.50
> - 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 c-make-inherited-keymap, since it's not used any more.

It is not clear to me how to adapt a 3rd party derived mode to
this. Granted, it was never clear to me how to make a mode derived from
CC mode, but that's another thread.

For mode derivation, either I have

(define-derived-mode foo++-mode c++-mode "Foo++"
 ...)

In which case there will be a parent c++-mode-map and a C++ menu present
when there shouldn't be, or:

(define-derived-mode foo++-mode c-derivative-mode "Foo++"
 ...)

and fontification is broken.

I've attached an example:


[-- Attachment #2: freefem++ mode --]
[-- Type: application/emacs-lisp, Size: 9585 bytes --]

bug#21465: [PATCH] CC-modes hierarchy

[Stefan Monnier]

> It is not clear to me how to adapt a 3rd party derived mode to
> this.

Hmm... I'm missing something.  I don't see how your problem is linked to
my patch?

> For mode derivation, either I have

> (define-derived-mode foo++-mode c++-mode "Foo++"
>  ...)

> In which case there will be a parent c++-mode-map and a C++ menu present

But that's already the case with the code in (say) Emacs-24, no?

> when there shouldn't be, or:
> (define-derived-mode foo++-mode c-derivative-mode "Foo++"
>  ...)
> and fontification is broken.

How is it broken?


        Stefan

bug#21465: [PATCH] CC-modes hierarchy

[Mark Oteiza]

On 13/09/15 at 09:25am, Stefan Monnier wrote:
> > It is not clear to me how to adapt a 3rd party derived mode to
> > this.
> 
> Hmm... I'm missing something.  I don't see how your problem is linked to
> my patch?

The patch makes changes which will break modes in emacs 25, so I'm
interested in knowing how to adapt, in particular, so my mode (and
others) can be backward compatible.

I think I have figured out how to accomodate this change: just checking
for c-make-inherited-keymap and c-derivative-mode, so I am happy.

> > For mode derivation, either I have
> 
> > (define-derived-mode foo++-mode c++-mode "Foo++"
> >  ...)
> 
> > In which case there will be a parent c++-mode-map and a C++ menu present
> 
> But that's already the case with the code in (say) Emacs-24, no?

Nope, for some reason, doing (c-make-inherited-keymap) in the map
definition in 24, I end up only with a Foo++ menu.  Simply using
(make-keymap), I'd end with with both Foo++ and C++ menus.

> > when there shouldn't be, or:
> > (define-derived-mode foo++-mode c-derivative-mode "Foo++"
> >  ...)
> > and fontification is broken.
> 
> How is it broken?

Oh, it was broken because I was using (make-syntax-table) instead of
(funcall (c-lang-const c-make-mode-syntax-table c)). It looks like
c-derivative-mode comes with no syntax table, which is alright.

bug#21465: [PATCH] CC-modes hierarchy

[Stefan Monnier]

> Nope, for some reason, doing (c-make-inherited-keymap) in the map
> definition in 24, I end up only with a Foo++ menu.  Simply using
> (make-keymap), I'd end with with both Foo++ and C++ menus.

Oh, you mean that your code uses c-make-inherited-keymap and the change
breaks your code, so you then try to fix it by replacing it with
make-sparse-keymap or make-keymap.

Indeed, that's not the right fix.  The right fix is to complain about
the removal of c-make-inherited-keymap because it is used by external
CC-mode modes.

BTW, you don't need c-make-inherited-keymap.  Instead you need

   (defvar foo++-mode-map
     (let ((map (make-sparse-keymap)))
       (set-keymap-parent map c-mode-base-map)
       ...
       map))

This should be just as backward compatible as using
c-make-inherited-keymap (and "backward" includes XEmacs, here).

>> > when there shouldn't be, or:
>> > (define-derived-mode foo++-mode c-derivative-mode "Foo++"
>> >  ...)
>> > and fontification is broken.
>> 
>> How is it broken?

> Oh, it was broken because I was using (make-syntax-table) instead of
> (funcall (c-lang-const c-make-mode-syntax-table c)). It looks like
> c-derivative-mode comes with no syntax table, which is alright.

Indeed, we could set C's syntax table in c-derivative-mode.  That would
make a lot of sense, thanks.  The proposed patch just introduces
c-derivative-mode as a way to make the hierarchy more visible, but it
doesn't make c-derivative-mode usable on its own.  You could argue that
c-derivative-mode should be the same as c-mode, but my patch does not
try to do that (yet?).


        Stefan

bug#21465: [PATCH] CC-modes hierarchy

[Mark Oteiza]

On 13/09/15 at 04:24pm, Stefan Monnier wrote:
> > Nope, for some reason, doing (c-make-inherited-keymap) in the map
> > definition in 24, I end up only with a Foo++ menu.  Simply using
> > (make-keymap), I'd end with with both Foo++ and C++ menus.
> 
> Oh, you mean that your code uses c-make-inherited-keymap and the change
> breaks your code, so you then try to fix it by replacing it with
> make-sparse-keymap or make-keymap.
> 
> Indeed, that's not the right fix.  The right fix is to complain about
> the removal of c-make-inherited-keymap because it is used by external
> CC-mode modes.
> 
> BTW, you don't need c-make-inherited-keymap.  Instead you need
> 
>    (defvar foo++-mode-map
>      (let ((map (make-sparse-keymap)))
>        (set-keymap-parent map c-mode-base-map)
>        ...
>        map))
> 
> This should be just as backward compatible as using
> c-make-inherited-keymap (and "backward" includes XEmacs, here).

That works, thanks.

> >> > when there shouldn't be, or:
> >> > (define-derived-mode foo++-mode c-derivative-mode "Foo++"
> >> >  ...)
> >> > and fontification is broken.
> >> 
> >> How is it broken?
> 
> > Oh, it was broken because I was using (make-syntax-table) instead of
> > (funcall (c-lang-const c-make-mode-syntax-table c)). It looks like
> > c-derivative-mode comes with no syntax table, which is alright.
> 
> Indeed, we could set C's syntax table in c-derivative-mode.  That would
> make a lot of sense, thanks.  The proposed patch just introduces
> c-derivative-mode as a way to make the hierarchy more visible, but it
> doesn't make c-derivative-mode usable on its own.  You could argue that
> c-derivative-mode should be the same as c-mode, but my patch does not
> try to do that (yet?).

Oh, and I guess it's not necessary to do the (funcall …) since it's
already c-mode-syntax-table. Similar to the keymap, I can do

 (set-char-table-parent table c-mode-syntax-table)

It would be nice if c-derivative-mode did that work for us.

Then, if I didn't want the c-mode keymap or syntax table, I could set
the parent of my derived table to nil. That's what I did for a mode that
I recently made derive from conf-mode. I didn't want conf-mode's keymap.

bug#21465: [PATCH] CC-modes hierarchy

[Alan Mackenzie]

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

bug#21465: [PATCH] CC-modes hierarchy

[Stefan Monnier]

> c-after-font-lock-init surely isn't broken.  c-after-change is ALWAYS on
> after-change-functions.

No, it's not.  Not in my sm-awk-mode which derives from awk-mode.
Or rather, I don't want it there and c-after-font-lock-init forces it
down my throat again after I removed it.

> Without it, CC Mode simply wouldn't function.

It does.

Besides, my patch does not remove c-after-change from
after-change-functions.  It just stops c-after-font-lock-init from
re-adding it if someone decided to remove it.  AFAIK c-after-change is
never removed from after-change-functions by accident, so re-adding it
blindly is a bug.

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

The text you quote is my answer to the question.

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

Indeed, I don't think it's urgent to fix it, but I think it deserves
a comment.


        Stefan

bug#21465: [PATCH] CC-modes hierarchy

[Zhang Kai Yu]

This is useful feature.

For example, when user set up auto completion, since clang provides completion to C, C++, and Objective-C, user just setup auto completion onto the common hook. When user open a php file, C stuff starts to auto completion.

Also, C snippets is required in C++ and Objective-C, but do not make sense in php.

C++ and Objective-C contains C, however php not. There are some keywords in C are not keywords in php, vice versa. It has structure similar to C but totally different language and running environment.

IMHO we should adapt to this.

bug#21465: [PATCH] CC-modes hierarchy

[Alan Mackenzie]

Hello, Stefan.

On Mon, Sep 14, 2015 at 09:06:06PM -0400, Stefan Monnier wrote:
> > c-after-font-lock-init surely isn't broken.  c-after-change is ALWAYS on
> > after-change-functions.

> No, it's not.  Not in my sm-awk-mode which derives from awk-mode.
> Or rather, I don't want it there and c-after-font-lock-init forces it
> down my throat again after I removed it.

> > Without it, CC Mode simply wouldn't function.

> It does.

It may appear to, but c-after-change does important things like
invalidating caches, and preparing the buffer for font locking.  Sooner
or later, something will go wrong.  (Unless you've put in an
sm-c-after-change, or something like that.)  But you probably know this.

This is one of these "please don't report any bugs whilst this is
active".

> Besides, my patch does not remove c-after-change from
> after-change-functions.  It just stops c-after-font-lock-init from
> re-adding it if someone decided to remove it.

The impression should not be given that c-after-change is in any way an
optional extra.  It's essential to CC Mode.

Why do you want to remove it from your setup?

> AFAIK c-after-change is never removed from after-change-functions by
> accident, so re-adding it blindly is a bug.

I don't think so.  Anybody advanced/foolish enough to remove it will
know how to remove it even after c-after-font-lock-init has inserted it.
This isn't something that should be encouraged.

Again, why do you want to take it out of your Awk Mode?

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#21465: [PATCH] CC-modes hierarchy

[Stefan Monnier]

> It may appear to, but c-after-change does important things like
> invalidating caches, and preparing the buffer for font locking.  Sooner
> or later, something will go wrong.  (Unless you've put in an
> sm-c-after-change, or something like that.)  But you probably know this.

That's right.

> This is one of these "please don't report any bugs whilst this is
> active".

I still have no idea why you think it's right for c-after-font-lock-init
to add c-after-change to after-change-functions if it's not there in the
first place.
I understand why you might not consider it as a bug, but why do you
consider it as a feature?

> Again, why do you want to take it out of your Awk Mode?

Because I'm trying to make my awk-mode behave in "the standard way" used
by all other (non-cc) major modes.  E.g. using syntax-propertize.

I know we disagree on whether "like everyone else" is a quality or
a defect, but I'd ask you to try at least not to actively and
gratuitously prevent me from writing a mode that uses the cc-mode
infrastructure yet behaves a bit more "like everyone else".

So, to put it some other way: can you give me a concrete example where
my change to c-after-font-lock-init is harmful?


        Stefan

bug#21465: [PATCH] CC-modes hierarchy

[Alan Mackenzie]

Hello, Stefan.

On Wed, Sep 16, 2015 at 09:49:49PM -0400, Stefan Monnier wrote:
> > It may appear to, but c-after-change does important things like
> > invalidating caches, and preparing the buffer for font locking.  Sooner
> > or later, something will go wrong.  (Unless you've put in an
> > sm-c-after-change, or something like that.)  But you probably know this.

> That's right.

> > This is one of these "please don't report any bugs whilst this is
> > active".

> I still have no idea why you think it's right for c-after-font-lock-init
> to add c-after-change to after-change-functions if it's not there in the
> first place.
> I understand why you might not consider it as a bug, but why do you
> consider it as a feature?

We're bikeshedding.

I suppose it doesn't really matter if we check for the presence of
c-after-change first.  It's more code, that's all.  But it doesn't
really matter.  Hopefully _nobody_ (except someone like yourself who
knows what they're doing) is going to try running without
c-after-change.

> > Again, why do you want to take it out of your Awk Mode?

> Because I'm trying to make my awk-mode behave in "the standard way" used
> by all other (non-cc) major modes.  E.g. using syntax-propertize.

Ah, OK.

> I know we disagree on whether "like everyone else" is a quality or
> a defect, but I'd ask you to try at least not to actively and
> gratuitously prevent me from writing a mode that uses the cc-mode
> infrastructure yet behaves a bit more "like everyone else".

> So, to put it some other way: can you give me a concrete example where
> my change to c-after-font-lock-init is harmful?

Provided you have the functionality of c-after-change in there correctly
somewhere, then it shouldn't be harmful.

So I withdraw my objection to that change to c-after-font-lock-init.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#21465: [PATCH] CC-modes hierarchy

[Jostein Kjønigsen]

> Any objection to the patch below?
> 
> It does the following:
> - Remove c-make-inherited-keymap, since it's not used any more.
> 
> 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"

csharp-mode[1] is not hosted on ELPA or in Emacs core, so I'm not
going to blame Emacs developers for not checking it, but it may
have issues with this patch.

csharp-mode has gone halfway through a transition to use of
"make-derive-mode", but it's not 100% there.

That means that it currently (still) uses "c-make-inherited-keymap" to
configure itself[2].

If fixing it on my end is easy, I guess that will be easier than
objecting to this patch. I see there's a suggestion posted[3] which I
can try out.

Just thought I'd put it out there that there are indeed more 3rd party
modules depending on the current implementation.

[1] https://github.com/josteink/csharp-mode
[2]
https://github.com/josteink/csharp-mode/blob/master/csharp-mode.el#L1428-L1430
[3] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21465#17

--
Jostein Kjønigsen
jostein@kjonigsen.net / jostein@secure.kjonigsen.net

bug#21465: [PATCH] CC-modes hierarchy

[Stefan Monnier]

> That means that it currently (still) uses "c-make-inherited-keymap" to
> configure itself[2].

Thanks, someone already pointed out that this function needs to stay for
backward compatibility.

> Just thought I'd put it out there that there are indeed more 3rd party
> modules depending on the current implementation.

Oh, yes.  Actually, the patch's first hunk lists those externally
maintained modes that use cc-mode (at least those I know of, and indeed,
csharp-mode was missing) and I guess most of them are in the
same situation.


        Stefan

bug#21465: [PATCH] CC-modes hierarchy

[Stefan Monnier]

> So I withdraw my objection to that change to c-after-font-lock-init.

Thanks, I installed that hunk into master,


        Stefan

bug#21465: [PATCH] CC-modes hierarchy

[Stefan Monnier]

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

You already have this layer, with c-mode-common-hook and
c-mode-base-map.  My patch just makes this layering more standard and
then takes advantage of it to share some code.

Here's another version of the patch with the following changes:
- Got rid of c-derivative-mode (which I still use at other places in my
  local patches, but for now, I won't push for it any more).
- Keep c-make-inherited-keymap for backward compatibility.
- Fix the "c-mode-hook is run twice" bug, using the same hack as is used
  by define-globalized-minor-mode.
The third point also makes the c-mode-common "extra layer" more useful
since that hack is added in there.

Any objections to this version?


        Stefan


It does the following:
- Move code common to all CC-mode major modes to a c-mode-common-mode function.
- Remove code that's redundant with what define-derived-mode does:
  - set local-map
  - set syntax-table
  - set keymap parent
  - run mode hooks
- Mark c-make-inherited-keymap and c-run-mode-hooks obsolete.
- Use inhibit-modification-hooks rather than binding
  *-change-functions to nil.


diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el
index 1b6a233..c476117 100644
--- a/lisp/progmodes/cc-mode.el
+++ b/lisp/progmodes/cc-mode.el
@@ -71,6 +71,19 @@
 ;;
 ;;    http://lists.sourceforge.net/mailman/listinfo/cc-mode-announce
 
+;; Externally maintained major modes which use CC-mode's engine:
+;; - cuda-mode
+;; - csharp-mode (https://github.com/josteink/csharp-mode)
+;; - haxe-mode
+;; - d-mode
+;; - dart-mode
+;; - cc-php-js-cs.el
+;; - php-mode
+;; - yang-mode
+;; - math-mode (mathematica)
+;; - unrealscript-mode
+;; - groovy-mode
+
 ;;; Code:
 
 ;; For Emacs < 22.2.
@@ -215,6 +228,8 @@ control).  See \"cc-mode.el\" for more info."
      ;; incompatible
      (t (error "CC Mode is incompatible with this version of Emacs")))
     map))
+(make-obsolete 'c-make-inherited-keymap
+	       "Use make-sparse-keymap + (set-keymap-parent c-mode-base-map); or derive from c-mode-common" "25.1")
 
 (defun c-define-abbrev-table (name defs &optional doc)
   ;; Compatibility wrapper for `define-abbrev' which passes a non-nil
@@ -667,7 +682,7 @@ compatible with old code; callers should always specify it."
     (setq c-new-BEG (point-min))
     (setq c-new-END (point-max))
     (save-excursion
-      (let (before-change-functions after-change-functions)
+      (let ((inhibit-modification-hooks t))
 	(mapc (lambda (fn)
 		(funcall fn (point-min) (point-max)))
 	      c-get-state-before-change-functions)
@@ -835,6 +850,7 @@ Note that the style variables are always made local to the buffer."
   (if (cc-bytecomp-fboundp 'run-mode-hooks)
       `(run-mode-hooks ,@hooks)
     `(progn ,@(mapcar (lambda (hook) `(run-hooks ,hook)) hooks))))
+(make-obsolete 'c-run-mode-hooks "derive your mode from c-common-mode" "25.1")
 
 \f
 ;;; Change hooks, linking with Font Lock and electric-indent-mode.
@@ -1219,7 +1235,7 @@ Note that the style variables are always made local to the buffer."
       (backward-char))			; back over (, [, <.
     (and (/= new-pos pos) new-pos)))
 
-(defun c-change-expand-fl-region (beg end old-len)
+(defun c-change-expand-fl-region (_beg _end _old-len)
   ;; Expand the region (c-new-BEG c-new-END) to an after-change font-lock
   ;; region.  This will usually be the smallest sequence of whole lines
   ;; containing `c-new-BEG' and `c-new-END', but if `c-new-BEG' is in a
@@ -1402,6 +1418,35 @@ This function is called from `c-common-init', once per mode initialization."
     (c-update-modeline)))
 
 \f
+(defvar c-mode-common-map c-mode-base-map)
+
+(defvar c-mode-common-update-mode-lines ()
+  "List of buffers where we should update the mode line.")
+
+(defun c-mode-common-update-mode-lines ()
+  (while c-mode-common-update-mode-lines
+    (let ((buf (pop c-mode-common-update-mode-lines)))
+      (when (buffer-live-p buf)
+	(with-current-buffer (c-update-modeline)))))
+  (remove-hook 'post-command-hook #'c-mode-common-update-mode-lines)
+  (remove-hook 'find-file-hook #'c-mode-common-update-mode-lines))
+
+(define-derived-mode c-mode-common prog-mode "CC-generic"
+  "Pseudo major mode, parent of all modes using the CC engine."
+  (c-initialize-cc-mode t)
+  (setq abbrev-mode t)  ;; Used for c-electric-continued-statement!
+  ;; We want to update the mode-line but *after* the major mode's hooks
+  ;; have been run.
+  ;; FIXME: Ideally, we'd just use a mode-line entry that's computed
+  ;; dynamically, but it's not clear how to do that (we could use
+  ;; `mode-line-process' but that would look weird if the user has decided to
+  ;; put mode-line-process elsewhere than immediately to the right of the major
+  ;; mode's name), so for now we'll use the ugly hack below, similar to the one
+  ;; used by `define-globalized-minor-mode'.
+  (push (current-buffer) c-mode-common-update-mode-lines)
+  (add-hook 'post-command-hook #'c-mode-common-update-mode-lines)
+  (add-hook 'find-file-hook #'c-mode-common-update-mode-lines))
+
 ;; Support for C
 
 (defvar c-mode-syntax-table
@@ -1414,7 +1459,7 @@ This function is called from `c-common-init', once per mode initialization."
   "Abbreviation table used in c-mode buffers.")
 
 (defvar c-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for C.
     (define-key map "\C-c\C-e"  'c-macro-expand)
     map)
@@ -1455,7 +1500,7 @@ This function is called from `c-common-init', once per mode initialization."
 (unless (fboundp 'prog-mode) (defalias 'prog-mode 'fundamental-mode))
 
 ;;;###autoload
-(define-derived-mode c-mode prog-mode "C"
+(define-derived-mode c-mode c-mode-common "C"
   "Major mode for editing C code.
 
 To submit a problem report, enter `\\[c-submit-bug-report]' from a
@@ -1470,18 +1515,11 @@ initialization, then `c-mode-hook'.
 
 Key bindings:
 \\{c-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table c-mode-syntax-table)
-  (setq local-abbrev-table c-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map c-mode-map)
   (c-init-language-vars-for 'c-mode)
   (c-make-macro-with-semi-re) ; matches macro names whose expansion ends with ;
   (c-common-init 'c-mode)
   (easy-menu-add c-c-menu)
-  (cc-imenu-init cc-imenu-c-generic-expression)
-  (c-run-mode-hooks 'c-mode-common-hook 'c-mode-hook)
-  (c-update-modeline))
+  (cc-imenu-init cc-imenu-c-generic-expression))
 
 \f
 ;; Support for C++
@@ -1497,7 +1535,7 @@ Key bindings:
   "Abbreviation table used in c++-mode buffers.")
 
 (defvar c++-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for C++.
     (define-key map "\C-c\C-e" 'c-macro-expand)
     (define-key map "\C-c:"    'c-scope-operator)
@@ -1510,7 +1548,7 @@ Key bindings:
 		  (cons "C++" (c-lang-const c-mode-menu c++)))
 
 ;;;###autoload
-(define-derived-mode c++-mode prog-mode "C++"
+(define-derived-mode c++-mode c-mode-common "C++"
   "Major mode for editing C++ code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from a
 c++-mode buffer.  This automatically sets up a mail buffer with
@@ -1525,18 +1563,11 @@ initialization, then `c++-mode-hook'.
 
 Key bindings:
 \\{c++-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table c++-mode-syntax-table)
-  (setq local-abbrev-table c++-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map c++-mode-map)
   (c-init-language-vars-for 'c++-mode)
   (c-make-macro-with-semi-re) ; matches macro names whose expansion ends with ;
   (c-common-init 'c++-mode)
   (easy-menu-add c-c++-menu)
-  (cc-imenu-init cc-imenu-c++-generic-expression)
-  (c-run-mode-hooks 'c-mode-common-hook 'c++-mode-hook)
-  (c-update-modeline))
+  (cc-imenu-init cc-imenu-c++-generic-expression))
 
 \f
 ;; Support for Objective-C
@@ -1551,7 +1582,7 @@ Key bindings:
   "Abbreviation table used in objc-mode buffers.")
 
 (defvar objc-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for Objective-C.
     (define-key map "\C-c\C-e" 'c-macro-expand)
     map)
@@ -1563,7 +1594,7 @@ Key bindings:
 ;;;###autoload (add-to-list 'auto-mode-alist '("\\.m\\'" . objc-mode))
 
 ;;;###autoload
-(define-derived-mode objc-mode prog-mode "ObjC"
+(define-derived-mode objc-mode c-derivative-mode "ObjC"
   "Major mode for editing Objective C code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from an
 objc-mode buffer.  This automatically sets up a mail buffer with
@@ -1578,18 +1609,11 @@ initialization, then `objc-mode-hook'.
 
 Key bindings:
 \\{objc-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table objc-mode-syntax-table)
-  (setq local-abbrev-table objc-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map objc-mode-map)
   (c-init-language-vars-for 'objc-mode)
   (c-make-macro-with-semi-re) ; matches macro names whose expansion ends with ;
   (c-common-init 'objc-mode)
   (easy-menu-add c-objc-menu)
-  (cc-imenu-init nil 'cc-imenu-objc-function)
-  (c-run-mode-hooks 'c-mode-common-hook 'objc-mode-hook)
-  (c-update-modeline))
+  (cc-imenu-init nil 'cc-imenu-objc-function))
 
 \f
 ;; Support for Java
@@ -1606,7 +1630,7 @@ Key bindings:
   "Abbreviation table used in java-mode buffers.")
 
 (defvar java-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for Java.
     map)
   "Keymap used in java-mode buffers.")
@@ -1624,7 +1648,7 @@ Key bindings:
 ;;;###autoload (add-to-list 'auto-mode-alist '("\\.java\\'" . java-mode))
 
 ;;;###autoload
-(define-derived-mode java-mode prog-mode "Java"
+(define-derived-mode java-mode c-mode-common "Java"
   "Major mode for editing Java code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from a
 java-mode buffer.  This automatically sets up a mail buffer with
@@ -1639,17 +1663,10 @@ initialization, then `java-mode-hook'.
 
 Key bindings:
 \\{java-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table java-mode-syntax-table)
-  (setq local-abbrev-table java-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map java-mode-map)
   (c-init-language-vars-for 'java-mode)
   (c-common-init 'java-mode)
   (easy-menu-add c-java-menu)
-  (cc-imenu-init cc-imenu-java-generic-expression)
-  (c-run-mode-hooks 'c-mode-common-hook 'java-mode-hook)
-  (c-update-modeline))
+  (cc-imenu-init cc-imenu-java-generic-expression))
 
 \f
 ;; Support for CORBA's IDL language
@@ -1662,7 +1679,7 @@ Key bindings:
   "Abbreviation table used in idl-mode buffers.")
 
 (defvar idl-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for IDL.
     map)
   "Keymap used in idl-mode buffers.")
@@ -1673,7 +1690,7 @@ Key bindings:
 ;;;###autoload (add-to-list 'auto-mode-alist '("\\.idl\\'" . idl-mode))
 
 ;;;###autoload
-(define-derived-mode idl-mode prog-mode "IDL"
+(define-derived-mode idl-mode c-mode-common "IDL"
   "Major mode for editing CORBA's IDL, PSDL and CIDL code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from an
 idl-mode buffer.  This automatically sets up a mail buffer with
@@ -1688,16 +1705,13 @@ initialization, then `idl-mode-hook'.
 
 Key bindings:
 \\{idl-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table idl-mode-syntax-table)
-  (setq local-abbrev-table idl-mode-abbrev-table)
-  (use-local-map idl-mode-map)
+  ;; No c-electric-continued-statement here, so we don't need abbrev-mode.
+  (kill-local-variable 'abbrev-mode)
   (c-init-language-vars-for 'idl-mode)
   (c-common-init 'idl-mode)
   (easy-menu-add c-idl-menu)
   ;;(cc-imenu-init cc-imenu-idl-generic-expression) ;TODO
-  (c-run-mode-hooks 'c-mode-common-hook 'idl-mode-hook)
-  (c-update-modeline))
+  )
 
 \f
 ;; Support for Pike
@@ -1712,7 +1726,7 @@ Key bindings:
   "Abbreviation table used in pike-mode buffers.")
 
 (defvar pike-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Additional bindings.
     (define-key map "\C-c\C-e" 'c-macro-expand)
     map)
@@ -1725,7 +1739,7 @@ Key bindings:
 ;;;###autoload (add-to-list 'interpreter-mode-alist '("pike" . pike-mode))
 
 ;;;###autoload
-(define-derived-mode pike-mode prog-mode "Pike"
+(define-derived-mode pike-mode c-mode-common "Pike"
   "Major mode for editing Pike code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from a
 pike-mode buffer.  This automatically sets up a mail buffer with
@@ -1740,17 +1754,11 @@ initialization, then `pike-mode-hook'.
 
 Key bindings:
 \\{pike-mode-map}"
-  (c-initialize-cc-mode t)
-  (set-syntax-table pike-mode-syntax-table)
-  (setq local-abbrev-table pike-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map pike-mode-map)
   (c-init-language-vars-for 'pike-mode)
   (c-common-init 'pike-mode)
   (easy-menu-add c-pike-menu)
   ;;(cc-imenu-init cc-imenu-pike-generic-expression) ;TODO
-  (c-run-mode-hooks 'c-mode-common-hook 'pike-mode-hook)
-  (c-update-modeline))
+  )
 
 \f
 ;; Support for AWK
@@ -1767,11 +1775,11 @@ Key bindings:
   "Abbreviation table used in awk-mode buffers.")
 
 (defvar awk-mode-map
-  (let ((map (c-make-inherited-keymap)))
+  (let ((map (make-sparse-keymap)))
     ;; Add bindings which are only useful for awk.
-    (define-key map "#" 'self-insert-command)
-    (define-key map "/" 'self-insert-command)
-    (define-key map "*" 'self-insert-command)
+    (define-key map "#" 'self-insert-command);Override electric parent binding.
+    (define-key map "/" 'self-insert-command);Override electric parent binding.
+    (define-key map "*" 'self-insert-command);Override electric parent binding.
     (define-key map "\C-c\C-n" 'undefined) ; #if doesn't exist in awk.
     (define-key map "\C-c\C-p" 'undefined)
     (define-key map "\C-c\C-u" 'undefined)
@@ -1790,7 +1798,7 @@ Key bindings:
 (declare-function c-awk-unstick-NL-prop "cc-awk" ())
 
 ;;;###autoload
-(define-derived-mode awk-mode prog-mode "AWK"
+(define-derived-mode awk-mode c-mode-common "AWK"
   "Major mode for editing AWK code.
 To submit a problem report, enter `\\[c-submit-bug-report]' from an
 awk-mode buffer.  This automatically sets up a mail buffer with version
@@ -1809,17 +1817,9 @@ Key bindings:
   ;; declared in cc-awk.el and hasn't yet been loaded.
   :syntax-table nil
   (require 'cc-awk)			; Added 2003/6/10.
-  (c-initialize-cc-mode t)
-  (set-syntax-table awk-mode-syntax-table)
-  (setq local-abbrev-table awk-mode-abbrev-table
-	abbrev-mode t)
-  (use-local-map awk-mode-map)
   (c-init-language-vars-for 'awk-mode)
   (c-common-init 'awk-mode)
-  (c-awk-unstick-NL-prop)
-
-  (c-run-mode-hooks 'c-mode-common-hook 'awk-mode-hook)
-  (c-update-modeline))
+  (c-awk-unstick-NL-prop))
 
 \f
 ;; bug reporting
diff --git a/lisp/progmodes/cc-defs.el b/lisp/progmodes/cc-defs.el
index 6bd5815..f4b54e3 100644
--- a/lisp/progmodes/cc-defs.el
+++ b/lisp/progmodes/cc-defs.el
@@ -510,7 +510,7 @@ wouldn't be able to undo them.
 The return value is the value of the last form in BODY."
   `(let* ((modified (buffer-modified-p)) (buffer-undo-list t)
 	  (inhibit-read-only t) (inhibit-point-motion-hooks t)
-	  before-change-functions after-change-functions
+	  (inhibit-modification-hooks t)
 	  deactivate-mark
 	  buffer-file-name buffer-file-truename ; Prevent primitives checking
 						; for file modification

bug#21465: [PATCH] CC-modes hierarchy

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> You already have this layer, with c-mode-common-hook and
> c-mode-base-map.  My patch just makes this layering more standard and
> then takes advantage of it to share some code.
>
> Here's another version of the patch with the following changes:
> - Got rid of c-derivative-mode (which I still use at other places in my
>   local patches, but for now, I won't push for it any more).
> - Keep c-make-inherited-keymap for backward compatibility.
> - Fix the "c-mode-hook is run twice" bug, using the same hack as is used
>   by define-globalized-minor-mode.
> The third point also makes the c-mode-common "extra layer" more useful
> since that hack is added in there.
>
> Any objections to this version?

This was four years ago, and there apparently wasn't any response here?
Alan?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#21465: [PATCH] CC-modes hierarchy

[Alan Mackenzie]

Hello, Lars.

On Mon, Sep 07, 2020 at 18:52:00 +0200, Lars Ingebrigtsen wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > You already have this layer, with c-mode-common-hook and
> > c-mode-base-map.  My patch just makes this layering more standard and
> > then takes advantage of it to share some code.

> > Here's another version of the patch with the following changes:
> > - Got rid of c-derivative-mode (which I still use at other places in my
> >   local patches, but for now, I won't push for it any more).
> > - Keep c-make-inherited-keymap for backward compatibility.
> > - Fix the "c-mode-hook is run twice" bug, using the same hack as is used
> >   by define-globalized-minor-mode.
> > The third point also makes the c-mode-common "extra layer" more useful
> > since that hack is added in there.

> > Any objections to this version?

> This was four years ago, and there apparently wasn't any response here?
> Alan?

Five years on, I'm still not keen on this change.  It is a large patch.
It would fragment the currently coherent functions c-mode, c++-mode and
so on.  It would extend the stack of modes by inserting a new,
meaningless mode, c-mode-common; this might induce hackers to try to
derive directly from c-mode-common (which wouldn't work) rather than one
of the genuine CC Mode modes.  It would magnify differences between the
Emacs version of CC Mode and the upstream version, or cause a lot of
work integrating the patch into the latter.

Of the above, I think it is the artificial introduction of c-mode-common
I'm least keen on.

I would be happiest if this bug could just be closed with "won't fix".

> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#21465: [PATCH] CC-modes hierarchy

[Stefan Monnier]

> I would be happiest if this bug could just be closed with "won't fix".

Agreed.  I got discouraged from contributing to CC-mode.


        Stefan "Using sm-c-mode instead ;-)"

bug#21465: [PATCH] CC-modes hierarchy

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I would be happiest if this bug could just be closed with "won't fix".
>
> Agreed.  I got discouraged from contributing to CC-mode.
>
>         Stefan "Using sm-c-mode instead ;-)"

OK, closed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no