bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21465: [PATCH] CC-modes hierarchy


From: Stefan Monnier
Subject: bug#21465: [PATCH] CC-modes hierarchy
Date: Sun, 13 Sep 2015 16:24:33 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]