bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Date: Mon, 02 Jul 2018 19:32:16 +0300

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

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

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

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

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]