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

From: Eli Zaretskii <[email-masked]>
Date: Mon, 02 Jul 2018 18:37:38 +0300

> From: [email-masked] (João Távora)
> Cc: [email-masked],  [email-masked]
> Date: Mon, 02 Jul 2018 16:28:53 +0100
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >>            (beginning-of-line line)
> >> -          (forward-char column)
> >> +          (ignore-errors (forward-char column))
> >> +          (unless (and (= (1+ (current-line)) line)
> >> +                       (= (current-column) column))
> >> +            (message "Intended xref location was line=%d, column=%d"
> >> +                     line column))
> >>            (point-marker))))))
> >
> > What will the last hunk do when a file changed, but the identifier was
> > still found?
> 
> The function is completely oblivious to the identifier being found or
> not.  So it would do what it does now: jump to the wrong location

And display the message, right?  If so, the message would be an
annoyance if displayed unconditionally, because at least the etags
back-end can cope with these calamities, and users rely on that (it
lets one re-generate TAGS only once in a blue moon).

Or maybe I misunderstand the context in which this code runs, in
which case ignore me.

> > AFAIR, the etags back-end is capable of doing that
> > (because it searches the file in the vicinity of the line/column if
> > not found at the exact location), and it's a valuable feature, for
> > obvious reasons.
> 
> IIUC, that's what I'm proposing in my point 3: add a "hint" field to
> xref-file-location and default that hint to the identifier being looked
> for.  If etags has code for that already, then great, we could try to
> share it

I don't think you can share that code, because it relies on the
contents of the TAGS file, where the 'etags' utility records not only
the position of the identifier, but also a string to search for it.