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

From: João Távora <[email-masked]>
Date: Mon, 10 Aug 2020 21:42:18 +0100

On 10.08.2020 15:59, Lars Ingebrigtsen wrote:

Hi Lars, thanks for pinging me.

> This was over two years ago, and there was some followup discussion
> between Dmitry and João, but I think the consensus here was that the
> patches fixes a real problem, ans should probably be applied?  As far as
> I can see, that never happened.

I read the discussion. As far as I know the problem reported originally
persists.

A small patch does exist, has two parts: 1 and 2.  Part 2 apparently had
some real problem that I don't understand anymore, not sure if it still
applies.  I seem to have said it was easy to fix, though it wouldn't
much matter if we could devise a much better fix, later known as number
3.

The rest of the discussion consists of hypothetical problems (about
seemingly hypothetical backends), leveled against that nr. 3 patch,
which seems never to have seen the light of day: I made the mistake of
tagging along with the hypotheticals and then probably ran out of time.

If I recall correctly, that better patch, were it to exist, would do
what is done by SLIME, the thing xref.el was based on when it was
originally written by Helmut Eller.  SLIME has done it for a very long
time and quite successfully: the objects that represent cross-references
contain optional extra bits of information -- hints -- which help,
heuristically, when locating the thing being looked for.

My fork of SLIME, SLY, hasn't yet switched to xref.el partly because of
xref.el's limitations in this regard.  Eglot would also benefit (the
original report concerns Eglot).

Alas, that nr 3 patch is vapourware.  Maybe I or someone will make it in
the future, and then we can talk about real stuff. I think we should
look to SLIME (and maybe Helmut?) for inspiration in fixing this, but I
don't have time to do this right now.

The original thread where xref.el is originally discussed is relevant
here, for posterity:

https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01253.html

João