[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
Message not available
bug#21465: [PATCH] CC-modes hierarchy, Zhang Kai Yu, 2015/09/15
bug#21465: [PATCH] CC-modes hierarchy, Jostein Kjønigsen, 2015/09/19