Re: Generalizing find-definition

[Stefan Monnier]

> > What happened to the other contenders?
> Nothing in particular.  The competition is still open.

Jorgen, what's your opinion?

> The elisp backend code needs to define a subclass of xref-backend-class
> and that can't be done without loading xref.el and eieio, I think.

Yes, I saw that.  I guess that's one advantage of the "plain function"
API compared to the EIEIO-based API.

> elisp-mode is needed to create the *scratch* buffer and it seemed to me
> that loading xref.el so early increases startup time for no good reason.

If it's needed for a normal "emacs -Q", then it should be preloaded.
And as it currently stands, I'd rather not preload EIEIO, so indeed the
elisp xref code can't be in elisp-mode.el.

> find-func.el might be a reasonable place for the elisp-xref
> backend code.

Indeed, that sounds like a good solution, thanks.

> The indirection makes it easier to autoload xref.el.

Hmm... I don't see why that'd make a difference, unless by "xref.el" you
mean "the file in which the elisp-xref-backend-function is defined".

> If emacs-lisp-mode wants to create a backend object it has to load
> xref.el first, which as I said above seems undesirable.

Indeed, I see that this makes a significant difference.

Another cosmetic issue I see with this EIEIO-based API is the need to
define a new class with a new instance which is really just a dummy
constant (no instance fields) and is only used to get the
method-dynamic-dispatch working (I guess in CLOS we could circumvent
this dummy class&instance by using an (eql <foo>) as the "class"
specializer).


        Stefan