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

Previous Next

Full log

View this message in rfc822 format

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

[Message part 1 (text/plain, inline)]

On Tue, Jul 3, 2018, 14:56 Dmitry Gutov <dgutov <at> yandex.ru> wrote:

>
>
> When xref-location-marker is inaccurate, it may lead to problems, like
> xref-query-replace-in-results sometimes performing replacements at the
> "auto-corrected", wrong positions.
>
> Maybe we can add a laxer version of this function that is only used when
> we know the user will be looking at the result directly (e.g. from
> xref-find-definitions, but not from xref-query-replace-in-results). I'm
> on the fence about xref-fined-references regarding this, because it also
> supports automatic replacement.
>

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.

>
>
> > 3. Number 2. could turn out to be brittle and annoying if we have
> > changed the file in the meantime (but probably not more so than jumping
> > to a wrong location).  So we could have a "hint" field in
> > xref-file-location (or a xref-hinted-file-location) that helps in
> > looking around the landing point for, say, a regexp, and puts point
> > there.  Historically, this technique is successfully used in SLIME.  We
> > could also reasonably default that field to the identifier being looked
> > for.
>
> I'm not sure this is a good idea. Certainly not the "defaulting to the
> identifier" bit. Because the identifier could e.g. look like
> namespace-name/symbol-name, where only "symbol-name" appears verbatim in
> the definition.



In that special case we will do no worse than the current version, wouldn't
we? So still a win on my book. And to do better for languages which do
present this problem would take very little work, especially if we take
advantage of inheritance and eieio slot methods.


I don't have much experience with LSP, but I imagine
> this could happen there, too (unless it only supports navigation to
> unqualified identifiers).
>
> Now, if hint is optional (and disabled by default), and extracting the
> relevant code from Etags is natural, I say go for it.
>
> But overall, I think individual backends that want "smarter" behavior
> should create their own "location" class, like Elisp does.
>

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

>

[Message part 2 (text/html, inline)]

Previous Next

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