It sounds like a goal is to slowly remove mode-local.
Yes and no: I'd like to remove the duplication that it entails.
E.g. I think defmethod's &context has made mode-local's
overloadable-functions largely redundant, so I think it would be good to
remove those overloadable-functions.
I haven't looked at the mode-local-variable part of mode-local.el, so
I don't plan on removing any of it for now, tho I think that if it
stays, it would be good to better integrate it into the rest of Emacs.
If there is a better official way to do the same thing that seems fine
with me.
My hope is that defmethod's &context covers those needs and that "it
seems fine" to you. Don't know if it's the case.
For this specific item, I'm curious what the alternative might be. The
obvious solution I can think of is making all the assignments for
functions and variables to all relevant modes, which feels error prone.
This was a way to specify similar modes for all overrides for this tool.
W.r.t the `mode-local-parent` property, it looks pretty ad-hoc (not to
say hackish): why not set `derived-mode-parent` instead? Of course, the
right way to set it is to change the mode so it sets it via
`define-derived-mode`. Otherwise you're in "it's kind of a child but
not really" territory.
BTW, regarding the above uses of define-child-mode, they've been reduced
down to just:
bovine/c.el: (define-child-mode c++-mode c-mode
bovine/el.el: (define-child-mode lisp-mode emacs-lisp-mode
I think the `lisp-mode` one is an error: lisp-mode is supposed to be for
common-lisp, which is clearly not a child of emacs-lisp-mode.
This said, AFAIK noone uses lisp-mode, everyone uses some other mode for
common-lisp, either the one from SLIME or the one from SLY.
The one for `c++-mode` is more tricky: I guess one could change cc-mode
to make c++-mode derive from c-mode instead of prog-mode, but that would
make it run c-mode-hook which some users might not like. Maybe we
should have a c-base-mode from which both c-mode and c++-mode derive?
This question is of course largely irrelevant since Alan will likely
never accept any such change in cc-mode.el. But I think it would be
perfectly fine to make define-child-mode set the derived-mode-parent
property in this particular case.
I'm not sure. David Engster did most of the work on mode-local. There used
to be the primitive semantic- only version you found that he wrapped up in
mode-local. Looking at this in retrospect, I'm not sure why the functions
installed with semantic-install-function-overrides weren't done using
mode-local more directly. If they were converted, then
semantic-install-function-overrides could be removed.
OK. I'm not sufficiently familiar with the code to see how it can be
changed to use define-overloadable-function instead of
semantic-install-function-overrides, but I'll try and find out.