bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations

[Dmitry Gutov]

On 7/3/18 5:50 PM, João Távora wrote:

> Right, this should go into xref-goto-xref (or whatever it is called) or 
> xref-find-definitions.  Or scratched, if it's too much work, because 
> it's not terribly useful.

I'm sure it will be useful in some situations, I'm just not sure about 
the odds.

> In that special case we will do no worse than the current version, 
> wouldn't we?

We would.

Say, we're looking for clojure.core/cons, and the marker leads us to 
"(defn cons" (the example is largely made up). The code looks for 
clojure.core/cons, doesn't find it, and signals an error (will it?).

Or worse, searches around and finds a verbatim reference to 
clojure.core/cons in a docstring somewhere in that file, and returns 
*that* location.

> At this point, I'm thinking of dismissing the whole thing, and voting to 
> deprecate xref-file-location entirely. Nobody uses it and Eglot will 
> probably use something else before this issue is solved. 

Err, it is used: in xref--collect-matches-1. And through it, in 
xref-collect-matches and xref-collect-references.

> It's a shame 
> we can't share code, but if we can't give a default class any kind of 
> useful behavior, we might as well not have this class in the first place.

We could. As long as we don't default to the identifier, and the backend 
has to explicitly provide the hint, we could be fine.