[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bad moves with xref-find-definitions

From: Stefan Monnier
Subject: Re: Bad moves with xref-find-definitions
Date: Sun, 26 Apr 2015 22:26:42 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]