Re: Generalizing find-definition

[Dmitry Gutov]

On 12/11/2014 05:07 PM, Stefan Monnier wrote:

>     (add-function :around (local xref-backend) #'elisp-xref-backend)

Okay, thanks for the reminder about nadvice.

I guess with this approach to function inheritance, there would be a 
different, bare-bones default value of xref-find-function, because I 
don't think I want to delegate to etags-xref-find from elisp-xref-find 
(and all other backends).

Anyway, having a separate xref-identifier-at-point-function should solve 
this problem in a different way.

> This should be called `xref-backend-function', to follow usual practice.

Right, thanks.

> Rename xref--xref to xref-xref, since it's clearly part of the API.

Or we can keep the class name private, and document that the function 
should return a list of xref values, using `xref-make'.

> A few comments:
> - As discussed earlier, `read-identifier' is probably a bad idea.
>    Replace it with a `completion-table' method, so the completing-read is
>    not in the backend but in xref.el.

Ok, apparently I missed some things in the older thread.

> - identifier-at-point should document more clearly that the return value
>    may be something else than a string.  AFAIK the only interesting
>    non-string non-nil case is to return a special value (e.g. a marker
>    or just `t' to stand to (point)) which stands for "let the
>    find-definitions code figure out the identifier at that place".
> - If we restrict identifier to "a string or nil or t", then we can get
>    rid of identifier-to-string.

All right, let's go with this, until a better idea comes up.

But note that AFAIK 99% of the time the identifier at point and 
prefix+suffix used by completion-at-point will be one and the same. 
Maybe it will make sense to unify these: for example, by naming the 
function identifier-bounds, and requiring it to return the beginning and 
the end of the identifier.

This pair of numbers (or maybe markers) would be useful to both 
find-definition functions that expect a string (just call 
buffer-substring beforehand), as well as those that need a buffer position.

>    a single backend function, but adding the other methods makes it
>    scream "I want to use OO", just like completion-tables do.

I wasn't aware they're considered a bad design already. :) That API is 
complicated, but not just because a function has many calling conventions.

>    then we need to split `xref-backend' into several variables:
>    - xref-find-function (can be used both for the `definitions' and for
>      the `references').
>    - xref-identifier-at-point-function.
>    - xref-identifier-completion-table.

Ok. (I should send the updated patch tonight).