Re: completion-at-point + semantic : erroneous error

[Stefan Monnier]

>>> I went back to mode-local to remind myself about it.  One of the things it
>>> handled was derived modes.
>> The `derived-mode` specializer I used in the patch for the &context part
>> correctly handles derived modes, as the name suggests.  It doesn't pay
>> attention to mode-local's `mode-local-parent` property, of course, only
>> to the `derived-mode-parent` property.
>>
>> [ BTW: I'd like to remove the `mode-local-parent` property.
>>    AFAICT it's only ever set by set-mode-local-parent which is only used by
>>    define-child-mode which is used as follows:
>>
>>      bovine/c.el:(define-child-mode c++-mode c-mode
>>      bovine/el.el:(define-child-mode lisp-mode emacs-lisp-mode
>>      html.el:(define-child-mode html-helper-mode html-mode
>>      wisent/javascript.el:(define-child-mode js-mode javascript-mode)
>>      wisent/javascript.el:(define-child-mode js-mode javascript-mode)
>>      wisent/python.el:(define-child-mode python-2-mode python-mode "Python 2 
>> mode")
>>      wisent/python.el:(define-child-mode python-3-mode python-mode "Python 3 
>> mode")
>>
>>    I suspect these could be replaced with other things.  WDYT? ]
>
> 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.

> On a side note, I was testing your patch that started this thread by
> converting more tests from CEDET on sourceforge to be part of Emacs.  It 
> has test files from a broader range of modes.  It doesn't test all the
> different overrides and modes, but if a goal is to factor mode-local 
> out, it could more definitively answer if any parsing infrastructure is
> broken given some of these proposed changes.  I'll try and get it 
> wrapped up and ready soon.

That would be great, yes,


        Stefan