[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 19:36:06 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 10/27/19 4:38 PM, Stefan Monnier wrote:

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.

Heh, sure.  The defmethod technique solves the same core problem, but has the added benefit of being clearer by not depending on a magic -default implementation somewhere.  It has been long enough I don't recall all the variants out there.

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.

This part of the mode-local system was put together to workaround the fact that we weren't modifying Emacs itself, and sometimes wanted to support multiple versions, and support other random modes not in Emacs.  The thing with c/c++ is a prime example.  If we externally define c++ as a child of c, will that break anything else?

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.

I can take a crack at this.  I'd like to figure out the test issues first though.


reply via email to

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