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

[Eric Ludlam]

On 10/24/19 4:17 PM, Stefan Monnier wrote:
> > 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.  If there is a 
better official way to do the same thing that seems fine with me.

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.

> > Also in your patch is a TODO about `with-mode-local'.  That with-mode-local
> > did more than just allow the next method call to dispatch correctly.  It
> > also sets up mode local variables, and other mode-local dispatchers for
> > anything the dispatched call might need.  In this case, the completion call
> > uses lots of other mode local dispatched functions.  with-mode-local doesn't
> > set the major-mode though.  Since all of CEDET is presumably still using
> > mode-local features, you will need both.
> Yes.  More importantly, I see that additionally to
> define-mode-local-override some functions are overloaded on
> a buffer-local basis via semantic-install-function-overrides.
> This doesn't fit well with the cl-defmethod system.  I can probably get
> rid of semantic-install-function-overrides, but do you happen to
> know if some functions are overloaded on a buffer-local basis from
> elsewhere than semantic-install-function-overrides?

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.

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.

Eric