From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations Date: Mon, 02 Jul 2018 19:32:16 +0300 Message-ID: <83muv9k38v.fsf@gnu.org> References: <87y3etsqb7.fsf@gmail.com> <83601xlmno.fsf@gnu.org> <87muv9sll6.fsf@gmail.com> <83po05k5rx.fsf@gnu.org> <87bmbpskl8.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1530550104 9017 195.159.176.226 (2 Jul 2018 16:48:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Jul 2018 16:48:24 +0000 (UTC) Cc: 32034@debbugs.gnu.org, dgutov@yandex.ru To: joaotavora@gmail.com (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 02 18:48:20 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fa1zv-0002E4-8p for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Jul 2018 18:48:19 +0200 Original-Received: from localhost ([::1]:34243 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fa222-0000fy-Gb for geb-bug-gnu-emacs@m.gmane.org; Mon, 02 Jul 2018 12:50:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fa1lB-0004L2-V5 for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2018 12:33:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fa1l8-0002sk-Rt for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2018 12:33:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35951) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fa1l8-0002sb-NV for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2018 12:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fa1l8-0007z3-Gs for bug-gnu-emacs@gnu.org; Mon, 02 Jul 2018 12:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Jul 2018 16:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32034 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 32034-submit@debbugs.gnu.org id=B32034.153054916430661 (code B ref 32034); Mon, 02 Jul 2018 16:33:02 +0000 Original-Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 16:32:44 +0000 Original-Received: from localhost ([127.0.0.1]:43848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fa1kp-0007yT-R7 for submit@debbugs.gnu.org; Mon, 02 Jul 2018 12:32:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fa1ko-0007yH-D0 for 32034@debbugs.gnu.org; Mon, 02 Jul 2018 12:32:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fa1ki-0002fc-4e for 32034@debbugs.gnu.org; Mon, 02 Jul 2018 12:32:37 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60780) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fa1kb-0002Z9-5P; Mon, 02 Jul 2018 12:32:29 -0400 Original-Received: from [176.228.60.248] (port=1685 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fa1ka-0001Gf-Gu; Mon, 02 Jul 2018 12:32:28 -0400 In-reply-to: <87bmbpskl8.fsf@gmail.com> (joaotavora@gmail.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:148107 Archived-At: > 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.