From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eric Ludlam <ericludlam@gmail.com>
Cc: Emacs Development <emacs-devel@gnu.org>,
Eric Ludlam <eric@siege-engine.com>
Subject: Re: completion-at-point + semantic : erroneous error
Date: Sun, 27 Oct 2019 16:38:54 -0400 [thread overview]
Message-ID: <jwvimoa6izk.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <a11ba42f-3251-b3cd-960f-c4db2d51584a@gmail.com> (Eric Ludlam's message of "Sun, 27 Oct 2019 08:35:15 -0400")
>>> 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
next prev parent reply other threads:[~2019-10-27 20:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 2:33 completion-at-point + semantic : erroneous error Eric Ludlam
2019-10-11 17:04 ` Stefan Monnier
2019-10-11 17:34 ` Stefan Monnier
2019-10-12 1:06 ` Eric Ludlam
2019-10-24 20:17 ` Stefan Monnier
2019-10-27 12:35 ` Eric Ludlam
2019-10-27 20:38 ` Stefan Monnier [this message]
2019-10-27 23:36 ` Eric Ludlam
2019-10-12 11:56 ` Eric Ludlam
2019-10-23 20:18 ` Stefan Monnier
2019-10-27 11:52 ` Eric Ludlam
2019-10-27 21:54 ` Stefan Monnier
2019-10-27 22:31 ` Eric Ludlam
2019-10-23 20:22 ` Stefan Monnier
2019-10-27 11:53 ` Eric Ludlam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvimoa6izk.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=eric@siege-engine.com \
--cc=ericludlam@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.