[Top][All Lists]

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

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

From: Dmitry Gutov
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Date: Tue, 3 Jul 2018 18:07:54 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

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.

reply via email to

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