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

["João Távora" <joaotavora@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: joaotavora@gmail.com (João Távora)
>> Cc: 32034@debbugs.gnu.org,  dgutov@yandex.ru
>> Date: Mon, 02 Jul 2018 16:50:27 +0100
>> 
>> > And display the message, right?
>> Not necessarily, if that line and column still exists.
> I was explicitly thinking about the case where they don't, for some
> reason, or that the line is there, but the column isn't (e.g., due to
> some TABs).

Yeah, but in those cases I want the message to display.  The definition
isn't there probably, so it's nice to display the message.

>> > 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).
>> That's what I wrote in the original message.  I added it under the
>> assumption that it would be less of an annoyance than silently jumping
>> to the wrong spot int he file.
> If the back-end can do its job even under these conditions, then the
> message would look like a regression.

Well it can't, so it won't :-)

>> No, I think your understanding is fine.  The current code is really
>> quite dumb.  The reason you don't come across it often is that the elisp
>> and etags backend use their own "location" class, xref-etags-location
>> and xref-elisp-location.  But eglot uses the xref-file-location class
>> bundled with xref (it could also use its own, but then what's the point
>> of having a built-in class for this?  perhaps none, in this case I move
>> to delete it)
>
> So neither etags nor elisp back-ends will ever go through this code,
> and will never show this message?  If so, maybe your patch is fine as
> it is.  Otherwise, maybe we should exempt those two back-ends from
> displaying the message?

The first applies.  What's more, noone in Emacs or in the ELPA repo uses
xref-file-location, directly or through inheritance.  

>
>> When you can, please comment on the possibility of fixing this in
>> emacs-26 or master.
>
> In case it wasn't clear, what I wrote _was_ my comment on that.  The
> code is a no-brainer, so the only aspect I worry about is whether it
> could introduce annoying messages where none are needed.  Other than
> that, I have no objections with having this on emacs-26, but I'd like
> to give Dmitry time to comment.

OK, let's give Dmitry time.  But, without trying to annoy you :-) there 
are 3 parts to this:

1. bug fix for when file doesn't exist (should error instead of making it)
2. bug fix for when file exists, but not location (it currently errors)
3. new feature, for robustness, search for id around landing point.

1 and 2 were in my patch.  But now I'm assuming you want 1, 2 and 3 in
emacs-26, in which case I'll try to base the id-searching bit from etags.

João