consult-xref assumes xref-file-location in consult-xref--candidates

[vkazanov]

Hi,

Thanks for the amazing, amazing tool.

I recently began work on an xref backend for a mode that can only have references within a current file. It is fine to only provide buffer xrefs in this case (i.e. a pair of (current-buffer) and a position within the buffer).

But it turns out consult-xref--candidates only supports file xrefs:

(defun consult-xref--candidates ()
  "Return xref candidate list."
  (let ((root (consult--project-root)))
    (mapcar (lambda (xref)
              (let* ((loc (xref-item-location xref))
                     (group (xref-location-group loc))
                     (group (if root (string-remove-prefix root group) group))
                     (cand (consult--format-file-line-match
                            group
                            (or (xref-location-line loc) 0)
                            (xref-item-summary xref))))
                (add-text-properties
                 0 1 `(consult-xref ,xref consult--prefix-group ,group) cand)
                cand))
            (funcall consult-xref--fetcher))))

And buffer xrefs are just collapsed into a single ref, while the original Xref UI shows them just fine.

Notably, consult-xref--preview does support xref-buffer-location. I believe the code above should also handle buffer-locations.

Thank you, sorry for not providing a patch

[minad]

Thanks for the feature request. I am happy to consider patches which improve consult-xref to support more xref location types.

[minad]

And buffer xrefs are just collapsed into a single ref, while the original Xref UI shows them just fine.

Did you also test the original completing-read xref UI?

[vkazanov]

@minad yes, sure.

At first I thought my backend was doing something wrong but then I edebug'ed into consult-xref and realized that all xref-buffer-locations degrade into a single line 0 reference. The original xref UI does properly show a bunch of references.

I'll debug this a bit more, and maybe propose a patch to fix this. I think it boils down to getting lines from buffer positions using (line-number-at-pos ref-pos) .

Any requirement for working with the code? how many emacs versions should the code work with?

[minad]

I think it boils down to getting lines from buffer positions using (line-number-at-pos ref-pos) .

This is likely not an acceptable fix, since line-number-at-pos is a slow function, scaling with O(buffer-size).

Could you please explain what the actual problem is? Why are your xref references deduplicated? Note that completing-read removes duplicates, but this is not specific to Consult or Vertico. It also happens with the default completion UI and also with the default xref completing-read.

[vkazanov]

That's correct, I would prefer not to translate xref-buffer-locations into xref-file-locations as that is inefficient.

Here's my xref-backend-references implementation:

(cl-defmethod xref-backend-references ((_ (eql beancount)) identifier)
  "Find references of IDENTIFIER."
  (let ((fname (buffer-file-name)))
    (cl-loop
     for (ref-id . ref-pos) in
     ;; find all symbol-likes (ref-id is a symbol name, ref-pos is a point)
     (beancount-collect-pos-alist beancount-account-regexp 0)
     ;; keep references that have the name we're looking for
     if (equal ref-id identifier)
     collect
     (xref-make ref-id
                 ;;; this is where i would prefer using xref-make-buffer-location instead of line-number-at-pos
                (xref-make-file-location
                 fname (line-number-at-pos ref-pos) 0)))))

But current implementation of consult-xref turns all xref-make-buffer-locations into symbols on a line 0 (zero). These get merged because all refs have the same symbol names.

[minad]

Okay, I've took another look at the xref machinery. It seems our only chance is indeed to take the xref-location-marker and turn it into a line number via line-number-at-pos. Otherwise we get duplicate candidates. But to be clear, this problem also exists for xref-show-definitions-completing-read, so it should maybe also be solved there?

EDIT: It also seems that xref-buffer-location is used nowhere in the Emacs tree. Therefore this problem may not have come up before?