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.