Re: xref--read-identifier should call project-identifier-completion-table?

[Dmitry Gutov]

On 08/03/2015 06:24 PM, Stephen Leake wrote:

> I'm not clear if you are just talking about the rename here (that's what
> you quoted), or the larger issue of having xref--read-identifier call
> project-identifier-completion-table.

A larger issue. The completion table just returns a list of strings.

> I'll assume you are talking about the larger issue.
>
> Obviously I'll have to override functions that use xref-find-function
> (and other similar function variables) as well, in my elisp project
> backend. One step at a time ...

Why override functions? Override the xref-find-function value instead.

But anyway, these are scheduled to become generic functions, I just 
haven't gotten around to it yet. After "delayed buffers" (from a nearby 
thread).

> > The natural extension of this approach would be to have a
> > project-xref-backend accessor, but do we really need that?
>
> I don't know what that would be; can you give a more complete
> description?

You'll have to wait until then anyway, and maybe it'll become obvious.

> The project backend should be fully determined by the result of
> (project-current). It is only the presence of the function variables
> used in non-dispatching functions that defeats that.

I can't confidently answer this yet.

> That's one approach. But I'd rather get rid of all of these function
> variables in my backend; they just confuse things.

I'd rather not add more methods than is strictly needed.

> That's the point of my proposed change; to allow backends to eliminate
> the use of the function variables.

xref-find-function will become a generic function either way.