[Top][All Lists]

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

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

From: Eric Ludlam
Subject: Re: completion-at-point + semantic : erroneous error
Date: Sun, 27 Oct 2019 08:35:15 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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 
     wisent/python.el:(define-child-mode python-3-mode python-mode "Python 3 

   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.


reply via email to

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