Re: Bad moves with xref-find-definitions

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> Backend has to figure out the "thing" anyways. From there building
> "textual representation" and passing back to xref is a triviality.

Apparently not, because the part of the backend which "figures it out"
might be in an external tool which simply doesn't offer the option to
build a textual representation for it.

> Also, you have to provide completions and textual representation of on
> C-u anyways.

In case the backend is as described above, the C-u path will lead to
suboptimal results, indeed, because it'll have to fallback on
other techniques.

> What do you currently do if there are multiple matching definitions of
> the "thing-at-point"? Prompt?

Yes, in the *xref* buffer.

> All I was trying to say is that tags are commonly useful alongside
> dynamic backends. Blindly replacing tags with an even very good
> backend is not the right direction IMW. Expecting from end users to
> solve this problem with add-function :before is unacceptable if there
> are way to fix it at Emacs level. 

I'm not talking about the end-user using add-function, but about the
major mode's xref's backend doing so.

> Different backends can figure different "things-at-point". It would be
> wise to try back-ends in turn, just like completion-at-point-functions
> does.

If the major mode adds the backends via (add-function :before-until ...)
that's exactly what will happen.


        Stefan