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

Previous Next

Full log

Message #41 received at 32034 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>
Cc: 32034 <at> debbugs.gnu.org
Subject: Re: bug#32034: 26.1; [PACTH] better xref-location-marker for
 imperfect file locations
Date: Tue, 3 Jul 2018 18:07:54 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.