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

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

[Stephen Leake]

xref--read-identifier uses a completion table set by the variable
xref-identifier-completion-table-function, which is normally
buffer-local, set by the major mode.

However, if I'm debugging an elisp package (ie JDEE), I want to be able
to search for elisp identifiers via C-u M-. from any buffer, not just
elisp buffers. Similarly, if I'm debugging an Ada package, I want to
search for Ada identifiers.

That means the identifier completion table is associated with the
current project, not the current mode.

Which means xref--read-identifier should call a project function to get
the completion-table:

(cl-defgeneric project-identifier-completion-table (project)
  "Return a completion table of identifiers in PROJECT."
  (when xref-identifier-completion-table-function
    (funcall xref-identifier-completion-table-function)))

(defun xref--read-identifier (prompt)
  "Return the identifier at point or read it from the minibuffer."
  (let ((id (funcall xref-identifier-at-point-function)))
    (cond ((or current-prefix-arg
               (not id)
               (xref--prompt-p this-command))
           (completing-read (if id
                                (format "%s (default %s): "
                                        (substring prompt 0 (string-match
                                                             "[ :]+\\'" prompt))
                                        id)
                              prompt)
                            (project-identifier-completion-table)
                            nil nil nil
                            'xref--read-identifier-history id))
          (t id))))

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.


Now I can override project-identifier-completion-table in a project
backend to give the behavior I need.

-- 
-- Stephe

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

[Dmitry Gutov]

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?

You'll get Elisp identifiers in completion, but won't be able to 
navigate to them.

The natural extension of this approach would be to have a 
project-xref-backend accessor, but do we really need 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.

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

[Stephen Leake]

Dmitry Gutov <dgutov@yandex.ru> 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

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.