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

[Stephen Leake]

Dmitry Gutov <address@hidden> writes:

> On 08/03/2015 12:47 PM, Stephen Leake wrote:
>
>> The default method for project-identifier-completion-table uses the
>> current xref buffer-local variable, so that's the same as the current
>> behavior. It might be better to change that to have a project- prefix.
>
> What's the use, if the rest of the operations still use the
> buffer-local value of xref-find-function?

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.

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

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

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.

> The same minor mode that enables your project globally could set
> xref-backend (the variable is still called xref-find-function, but not
> for long) in all buffers. It'll actually be a list, so you'll put an
> always-active element at its head, just like with
> project-find-functions.

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

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

-- 
-- Stephe