all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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: Thu, 24 Oct 2019 16:17:01 -0400	[thread overview]
Message-ID: <jwvzhhpq56m.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <fef1a0ee-57ce-d6de-71a1-bd5210b30cf7@gmail.com> (Eric Ludlam's message of "Fri, 11 Oct 2019 21:06:04 -0400")

> For the part of the patch replacing `define-overloadable-function' with
> methods, I was surprised by the &context syntax.  I've been away from emacs
> devel too long to be familiar with it, but the doc on it was
> helpful. mode-local.el was always a hack to overcome the mess that was
> managing behavior changes between modes while providing useful base
> functionality.  Updating to methods using &context seems like a fine way to
> solve the same problem.
>
> 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? ]

> Not sure what a "&context (major-mode ...) " does to know if it is
> derived from a parent mode or not. 

It looks at the derived-mode-parent property.

> 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?


        Stefan




  reply	other threads:[~2019-10-24 20:17 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 [this message]
2019-10-27 12:35         ` Eric Ludlam
2019-10-27 20:38           ` Stefan Monnier
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=jwvzhhpq56m.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.