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.