Re: Generalizing find-definition

[Stefan Monnier]

Alright, let's go ahead with this.  Can you send a "latest and greatest"
version of your code so I can install it into master?


        Stefan


>>>>> "Stefan" == Stefan Monnier <address@hidden> writes:

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