GNU logs - #32034, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Jul 2018 13:48:02 +0000
Resent-Message-ID: <handler.32034.B.153053922914245 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 32034 <at> debbugs.gnu.org
Cc: dgutov@HIDDEN
From: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
Date: Mon, 02 Jul 2018 14:46:52 +0100
Message-ID: <87y3etsqb7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi maintainers,

Observed this when working on Eglot, an Emacs LSP client.  Some LSP
servers, when asked about symbol definitions, make the mistake of
sending an non-existent or outdated path and location.

On the other hand, because xrefs come in potentially large numbers, a
sane xref backend will not check if a file exists before making
xref-file-location objects (neither should it check if the file contains
the purported location of the definition).  This can only reasonably be
done when the user decides to visit such a location.

So, currently, if the user chooses to visit a xref-file-location
pointing to a non-existing file, that file buffer is created
automatically and the command will probably error with an cryptic "End
of buffer" because of the `forward-char' call in the corresponding
xref-location-marker method.  The new empty buffer isn't even shown
which would at least help the user recognize the problem.

So:

1. xref-location-marker should check for `file-readable-p' before trying
to open the file, and if that fails issues an error ("File %s can't be
found.").

2. if the file is found, xref-location-marker should detect if the
location is indeed available in the file, and if it isn't, issue a
message.  In that case it should return a marker to the nearest possible
location.

3. Number 2. could turn out to be brittle and annoying if we have
changed the file in the meantime (but probably not more so than jumping
to a wrong location).  So we could have a "hint" field in
xref-file-location (or a xref-hinted-file-location) that helps in
looking around the landing point for, say, a regexp, and puts point
there.  Historically, this technique is successfully used in SLIME.  We
could also reasonably default that field to the identifier being looked
for.

The attached patch fixes 1. and 2.  It should probably go into emacs-26

Then, I'd like to know your opinions on 3., to go into master.

diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index b0bdd62ae9..d38328cccd 100644ppp
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -119,13 +119,19 @@ xref-make-file-location
     (with-current-buffer
         (or (get-file-buffer file)
             (let ((find-file-suppress-same-file-warnings t))
+              (unless (file-exists-p file)
+                (error "File %s doesn't exist!" file))
               (find-file-noselect file)))
       (save-restriction
         (widen)
         (save-excursion
           (goto-char (point-min))
           (beginning-of-line line)
-          (forward-char column)
+          (ignore-errors (forward-char column))
+          (unless (and (=3D (1+ (current-line)) line)
+                       (=3D (current-column) column))
+            (message "Intended xref location was line=3D%d, column=3D%d"
+                     line column))
           (point-marker))))))
=20
 (cl-defmethod xref-location-group ((l xref-file-location))

Jo=C3=A3o

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
Subject: bug#32034: Acknowledgement (26.1; [PACTH] better xref-location-marker
 for imperfect file locations)
Message-ID: <handler.32034.B.153053922914245.ack <at> debbugs.gnu.org>
References: <87y3etsqb7.fsf@HIDDEN>
X-Gnu-PR-Message: ack 32034
X-Gnu-PR-Package: emacs
Reply-To: 32034 <at> debbugs.gnu.org
Date: Mon, 02 Jul 2018 13:48:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 32034 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
32034: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D32034
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Robert Pluim <rpluim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Jul 2018 14:36:02 +0000
Resent-Message-ID: <handler.32034.B32034.153054213219467 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
From: Robert Pluim <rpluim@HIDDEN>
References: <87y3etsqb7.fsf@HIDDEN>
Mail-Copies-To: never
Gmane-Reply-To-List: yes
Date: Mon, 02 Jul 2018 16:35:20 +0200
In-Reply-To: <87y3etsqb7.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Mon, 02 Jul 2018 14:46:52 +0100")
Message-ID: <87po05d7tj.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

joaotavora@HIDDEN (Jo=C3=A3o T=C3=A1vora) writes:

>
> diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
> index b0bdd62ae9..d38328cccd 100644ppp
> --- a/lisp/progmodes/xref.el
> +++ b/lisp/progmodes/xref.el
> @@ -119,13 +119,19 @@ xref-make-file-location
>      (with-current-buffer
>          (or (get-file-buffer file)
>              (let ((find-file-suppress-same-file-warnings t))
> +              (unless (file-exists-p file)
> +                (error "File %s doesn't exist!" file))
>                (find-file-noselect file)))
>        (save-restriction
>          (widen)
>          (save-excursion
>            (goto-char (point-min))
>            (beginning-of-line line)
> -          (forward-char column)
> +          (ignore-errors (forward-char column))
> +          (unless (and (=3D (1+ (current-line)) line)
> +                       (=3D (current-column) column))
> +            (message "Intended xref location was line=3D%d, column=3D%d"
> +                     line column))
>            (point-marker))))))

I think the message could be clearer, the current one doesn=CA=BCt express
that something unexpected happened. How about

"Xref intended location line=3D%d, column=3D%d is out of range"

or similar.

Regards

Robert

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Jul 2018 14:49:01 +0000
Resent-Message-ID: <handler.32034.B32034.153054290820628 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
Date: Mon, 02 Jul 2018 17:47:39 +0300
Message-Id: <83601xlmno.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87y3etsqb7.fsf@HIDDEN> (joaotavora@HIDDEN)
References: <87y3etsqb7.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: joaotavora@HIDDEN (João Távora)
> Date: Mon, 02 Jul 2018 14:46:52 +0100
> Cc: dgutov@HIDDEN
> 
> The attached patch fixes 1. and 2.  It should probably go into emacs-26
> 
> Then, I'd like to know your opinions on 3., to go into master.
> 
> diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
> index b0bdd62ae9..d38328cccd 100644ppp
> --- a/lisp/progmodes/xref.el
> +++ b/lisp/progmodes/xref.el
> @@ -119,13 +119,19 @@ xref-make-file-location
>      (with-current-buffer
>          (or (get-file-buffer file)
>              (let ((find-file-suppress-same-file-warnings t))
> +              (unless (file-exists-p file)
> +                (error "File %s doesn't exist!" file))
>                (find-file-noselect file)))
>        (save-restriction
>          (widen)
>          (save-excursion
>            (goto-char (point-min))
>            (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?  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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Jul 2018 15:23:02 +0000
Resent-Message-ID: <handler.32034.B32034.153054493223883 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 32034 <at> debbugs.gnu.org
Cc: dgutov@HIDDEN
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153054493223883
          (code B ref 32034); Mon, 02 Jul 2018 15:23:02 +0000
Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 15:22:12 +0000
Received: from localhost ([127.0.0.1]:43718 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fa0eZ-0006D8-Qh
	for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:22:11 -0400
Received: from mail-wm0-f51.google.com ([74.125.82.51]:53969)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1fa0eY-0006Cw-Mb
 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:22:10 -0400
Received: by mail-wm0-f51.google.com with SMTP id b188-v6so9501538wme.3
 for <32034 <at> debbugs.gnu.org>; Mon, 02 Jul 2018 08:22:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=+bRSVkT4xW19hD2gC03se5SzChXDBLBzi0ZZPslgZLE=;
 b=TwwMUNakNDueIRTiKVS11AKYcD/zHq8EKo7HNSefDKB/DvLozXuEjYQH5U9GZuDYg8
 29YaIjbZbcw4SvhHu4Otq4lPtp7xJ1ceHboGimoG5jYa5KreSf8fK0+1ifS1Nq8R74uY
 seFgrCApJs6/xv27PKH4WOMnqFf8s6MYXKqVNNJ5mGCX8d73YHGXbdIyTdGAO0DcdMCn
 DVOwZ/c3lMNkWN05YUd57fUO4eaKpXax31eNYbtF8Hxase7xL7uK9vOyyJta5USxbOrt
 PEo8AiykupCGtSNTy2wxc3jaUW7QAhwFHlYRLkrwg/lsTsxg6f+GBrO9Op8VZar/Iao4
 hfwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=+bRSVkT4xW19hD2gC03se5SzChXDBLBzi0ZZPslgZLE=;
 b=TaL54XstOpRAoV94Q0mxFltyYll3idPUqDzRHlDaCzPrWce4hgIy0jl1afcgpD4cpo
 yBaJBIdoaYb2kuy+JP4i0ts+L4hJE1/KtRKLe/ZOm6ObC8JtAzH/XelhNmk4nX4NDnu/
 GRG3tTu+ZVLihWSoN+4FUVarxk1BqcG2AKx0+z/XFsuuPYDnmO6j+IhyMs9uYCz3OYi+
 JUm0KKhPmuVY2SiB6KQNbOjRLwVrE2CCpImdxg/4qg76xWE23GzQihqvDZ4opZPMCws+
 vrqOkZLpbg88Odsjjm8nvjauck16ioI6dTIZFVCXHt3A2RLO5DlJ0gsp24oXGyW1pPub
 fFdg==
X-Gm-Message-State: APt69E24yMlXJY1FBUc3sdg84xJnGG76XNv6KpNSSxN+yi11JYwNZaOQ
 lYkaCG0YeNCd/hB+RHHm51k=
X-Google-Smtp-Source: AAOMgpdCQ+pKvSXJPPwl63Bpf85lTJB1iOzGkUNjhFIQWXsaz0P+lnMqG9aKYU6Q+FBtR4GE5mGESA==
X-Received: by 2002:a1c:b8d2:: with SMTP id
 i201-v6mr6725792wmf.158.1530544924991; 
 Mon, 02 Jul 2018 08:22:04 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
 [94.62.139.188])
 by smtp.gmail.com with ESMTPSA id g4-v6sm16108250wrq.32.2018.07.02.08.22.03
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Mon, 02 Jul 2018 08:22:04 -0700 (PDT)
From: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
References: <87y3etsqb7.fsf@HIDDEN> <87po05d7tj.fsf@HIDDEN>
Date: Mon, 02 Jul 2018 16:22:01 +0100
In-Reply-To: <87po05d7tj.fsf@HIDDEN> (Robert Pluim's message of "Mon, 02
 Jul 2018 16:35:20 +0200")
Message-ID: <87r2klslwm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

Robert Pluim <rpluim@HIDDEN> writes:

>> +            (message "Intended xref location was line=3D%d, column=3D%d"
>> +                     line column))
>>            (point-marker))))))
>
> I think the message could be clearer, the current one doesn=CA=BCt express
> that something unexpected happened. How about
>
> "Xref intended location line=3D%d, column=3D%d is out of range"
>
> or similar.

OK, sounds reasonable.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Jul 2018 15:30:02 +0000
Resent-Message-ID: <handler.32034.B32034.153054534824560 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153054534824560
          (code B ref 32034); Mon, 02 Jul 2018 15:30:02 +0000
Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 15:29:08 +0000
Received: from localhost ([127.0.0.1]:43739 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fa0lH-0006O4-O2
	for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:29:07 -0400
Received: from mail-wr0-f169.google.com ([209.85.128.169]:46508)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1fa0lG-0006NT-SR
 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:29:07 -0400
Received: by mail-wr0-f169.google.com with SMTP id s11-v6so6731047wra.13
 for <32034 <at> debbugs.gnu.org>; Mon, 02 Jul 2018 08:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version;
 bh=K0iTcw1ElzouXTKC35Ih6BjHNzob7cbn0Lq/wVeygyU=;
 b=L+iMMhRiBLCmgC8lsVKMyh+GHaEaB4Oh/Ar9+/DwwlgvUxPbNWXnMv0EaZqO5xwnjd
 P8A67tcb0O0cDTQfYuweiIG3gRakYVGD2EdZcAm+RkMLktELEw6F5lXa0rmwd3FxgF1u
 A7WNSd3B+f0k5RshpbnqykXb+ROFma8zHbEhvkpbz6HIOPVdAqb9FcacjvSzEE/H7S4/
 cTiabczTy6wEM7nZ9+yXke7+fdVZNBTyb2u+qaUzuHjTmC0qUGhyADSFakJkaMv8SfbL
 V/QYqtCZPE5lUoPMZ7xzMoZuYhP9ti7/PKiK/NX5u13Kmt1EerlmcrcItXLy2V9dJYFL
 ZdRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=K0iTcw1ElzouXTKC35Ih6BjHNzob7cbn0Lq/wVeygyU=;
 b=ch2mAs5DBQ5YGIfNCg10Q0fq439xmV1B7IbAT2B7FWDQa0S4clwpBZi+B4vXqOv02j
 fnomXPh4//tHePyqFPqr0zxuLpp3+aTHbqLJO1vK2K8/J8W7tm1CkG4zoNGSaQwd9nj1
 BOkWiNqHag1oZOk86ePKBf1JajKYyRESkT457UM2ASQ2Ao46BcmgBhZP17/zDDRL1WIO
 3AfZIxkplfuZ7Kw4YQhV53BoE8P2A58md7oYBDL71C8/TRYj6tinMdFsACyyJHEAtPG+
 Y5nlF6gb+yV0yJE24zCzF7L81kM0pu8AfH16HToLX4baA7wuLpe7rrlkmdQmQ4MUNtuC
 PDsw==
X-Gm-Message-State: APt69E1zA6UQX+K0Ej7iMGMO3AO1pCJmlSbqvY8DoslG+nev+STz+3dB
 HILw8eyEcmLQBlnHFAiF8p8=
X-Google-Smtp-Source: AAOMgpf2jQdO2SRq0z7QVxs5FW4R2Gp6TAJP2Qb4zm8q2gkWljAtyIsxUYXfBHrcz/9tmn23LXIBTA==
X-Received: by 2002:adf:a706:: with SMTP id
 c6-v6mr20653757wrd.61.1530545340997; 
 Mon, 02 Jul 2018 08:29:00 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
 [94.62.139.188])
 by smtp.gmail.com with ESMTPSA id 131-v6sm20574446wmm.31.2018.07.02.08.28.59
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Mon, 02 Jul 2018 08:29:00 -0700 (PDT)
From: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
Date: Mon, 02 Jul 2018 16:28:53 +0100
In-Reply-To: <83601xlmno.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 02 Jul
 2018 17:47:39 +0300")
Message-ID: <87muv9sll6.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

Eli Zaretskii <eliz@HIDDEN> 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
(unless you're lucky and the change preserved the location of the
definition you're after).

> 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, but that would be for master right?  Or can 1, 2 and 3 go into
emacs-26?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Jul 2018 15:39:02 +0000
Resent-Message-ID: <handler.32034.B32034.153054588525520 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153054588525520
          (code B ref 32034); Mon, 02 Jul 2018 15:39:02 +0000
Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 15:38:05 +0000
Received: from localhost ([127.0.0.1]:43771 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fa0tx-0006dY-7e
	for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:38:05 -0400
Received: from eggs.gnu.org ([208.118.235.92]:37525)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1fa0tv-0006d4-CE
 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:38:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1fa0tp-0003TA-Ci
 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:37:58 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59821)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1fa0ti-0003P6-Iy; Mon, 02 Jul 2018 11:37:50 -0400
Received: from [176.228.60.248] (port=2121 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1fa0ti-0001qo-19; Mon, 02 Jul 2018 11:37:50 -0400
Date: Mon, 02 Jul 2018 18:37:38 +0300
Message-Id: <83po05k5rx.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87muv9sll6.fsf@HIDDEN> (joaotavora@HIDDEN)
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
 <87muv9sll6.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: joaotavora@HIDDEN (Jo�o T�vora)
> Cc: 32034 <at> debbugs.gnu.org,  dgutov@HIDDEN
> Date: Mon, 02 Jul 2018 16:28:53 +0100
> 
> Eli Zaretskii <eliz@HIDDEN> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Jul 2018 15:51:01 +0000
Resent-Message-ID: <handler.32034.B32034.153054663726685 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153054663726685
          (code B ref 32034); Mon, 02 Jul 2018 15:51:01 +0000
Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 15:50:37 +0000
Received: from localhost ([127.0.0.1]:43796 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fa164-0006wL-TY
	for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:50:37 -0400
Received: from mail-wr0-f179.google.com ([209.85.128.179]:46182)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1fa163-0006w8-L2
 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 11:50:36 -0400
Received: by mail-wr0-f179.google.com with SMTP id s11-v6so6796602wra.13
 for <32034 <at> debbugs.gnu.org>; Mon, 02 Jul 2018 08:50:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=83BzZa3riWYI+g0UbzR/jFLR88di/FA+jZZI3uAdTcw=;
 b=WSwh2XxAobbqi/uepfruJFyWYEh1w0+rdjMdHaOkvClCGf148xG7gcoYCDuB1H3ZzN
 IWM9KqZgUORa6g/hHNpYKVVVVk79EEyHxXSlgaHr+xb5pj+iY5VfcR/uD/pILbPmybSG
 OrhqGT92QfVC5l8xnpGya+vxloGywgrk5iH2ENtxjrOzq25lDPwXm4QyHrWBdDDpWLHY
 ndaH0mzvljEYeio6NkOKRSXAGXJDSrhVuXUvsCtJP2Nol5W4jwhOlwZzPRsFgiXaNSqE
 Cx5cJA9deymmXK42O5yTHUPL7aXfcD6Mf8olmknqLTuN1pHnAE3zpR/z4t4QnS56QyIh
 1gTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=83BzZa3riWYI+g0UbzR/jFLR88di/FA+jZZI3uAdTcw=;
 b=sxmc9zOi6vT77JEL0FNC9f14JFYGbfOc9akiWetPG/cFe7FDLdDBIbQDyxQ1qJQLCe
 vEfx4/iUm3JSwpbpwJEfSWsuY5kNaGhh9NPog0IeAQmYql31zsHvBGfmmk0ilqm3BuGf
 /LYq7LfDx2qA/LCmhI1K1kgPBWeE3B29RC7Gts28HR3DiPjVx92s9w9CdLPu9f8vAlal
 u521WX1Y4/sLAOzaU6AGxJZJ2xZTk6vWcHNQP0dVC4BbTorHuNt7tGQVFg1O6aGzXLd1
 zSIb4Qnnua5wiIX/NMmTceiJpaT8hGJTZwaWgyTVgpkVuvZOaqFwo9Y7VhG1B5R6D7Zr
 9Ubw==
X-Gm-Message-State: APt69E2LAOBCm6/PA8tJUXp9Wgs9OqW376UKHX6KNg+2uW8ujh4/uDG9
 kr1A4XfbKKJVvE/MyT3uS/M=
X-Google-Smtp-Source: AAOMgpdmPXc2+ClUnLTdVYXiqWzrCILiO/uOS8rg1JMjYojYUxILLmNufM0xlK2Q4GNrozQDTDngwg==
X-Received: by 2002:adf:f210:: with SMTP id
 p16-v6mr7768020wro.184.1530546629943; 
 Mon, 02 Jul 2018 08:50:29 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
 [94.62.139.188])
 by smtp.gmail.com with ESMTPSA id 131-v6sm20662998wmm.31.2018.07.02.08.50.28
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Mon, 02 Jul 2018 08:50:29 -0700 (PDT)
From: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
 <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN>
Date: Mon, 02 Jul 2018 16:50:27 +0100
In-Reply-To: <83po05k5rx.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 02 Jul
 2018 18:37:38 +0300")
Message-ID: <87bmbpskl8.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Eli Zaretskii writes: >> From: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o?=
    =?UTF-8?Q?T=C3=A1vora?=) >> Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN >> Date: Mon, 02
   Jul 2018 16:28:53 +0100 >> >> Eli Zaretskii 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? [...] 
 
 Content analysis details:   (1.1 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                             trust
                             [209.85.128.179 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.128.179 listed in wl.mailspike.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (joaotavora[at]gmail.com)
  0.1 FROM_EXCESS_BASE64     From: base64 encoded unnecessarily
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
  1.0 FREEMAIL_REPLY         From and body contain different freemails
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: joaotavora@HIDDEN (Jo=C3=A3o T=C3=A1vora)
>> Cc: 32034 <at> debbugs.gnu.org,  dgutov@HIDDEN
>> Date: Mon, 02 Jul 2018 16:28:53 +0100
>>=20
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>=20
>> >>            (beginning-of-line line)
>> >> -          (forward-char column)
>> >> +          (ignore-errors (forward-char column))
>> >> +          (unless (and (=3D (1+ (current-line)) line)
>> >> +                       (=3D (current-column) column))
>> >> +            (message "Intended xref location was line=3D%d, column=
=3D%d"
>> >> +                     line column))
>> >>            (point-marker))))))
>> >
>> > What will the last hunk do when a file changed, but the identifier was
>> > still found?
>>=20
>> 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?

Not necessarily, if that line and column still exists.

> 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.  The feature you want to add to the
relevant xref-location-marker method makes a lot of sense, but it's a
new feature nevertheless.

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

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)

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

I meant the code that searches for the string then, if it isn't too
trivial.

When you can, please comment on the possibility of fixing this in
emacs-26 or master.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Jul 2018 16:33:02 +0000
Resent-Message-ID: <handler.32034.B32034.153054916430661 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=)
Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153054916430661
          (code B ref 32034); Mon, 02 Jul 2018 16:33:02 +0000
Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 16:32:44 +0000
Received: from localhost ([127.0.0.1]:43848 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fa1kp-0007yT-R7
	for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 12:32:44 -0400
Received: from eggs.gnu.org ([208.118.235.92]:55320)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1fa1ko-0007yH-D0
 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 12:32:42 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1fa1ki-0002fc-4e
 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 12:32:37 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60780)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1fa1kb-0002Z9-5P; Mon, 02 Jul 2018 12:32:29 -0400
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 <eliz@HIDDEN>)
 id 1fa1ka-0001Gf-Gu; Mon, 02 Jul 2018 12:32:28 -0400
Date: Mon, 02 Jul 2018 19:32:16 +0300
Message-Id: <83muv9k38v.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87bmbpskl8.fsf@HIDDEN> (joaotavora@HIDDEN)
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
 <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN> <87bmbpskl8.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: joaotavora@HIDDEN (João Távora)
> Cc: 32034 <at> debbugs.gnu.org,  dgutov@HIDDEN
> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Jul 2018 16:56:02 +0000
Resent-Message-ID: <handler.32034.B32034.153055052232558 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153055052232558
          (code B ref 32034); Mon, 02 Jul 2018 16:56:02 +0000
Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 16:55:22 +0000
Received: from localhost ([127.0.0.1]:43854 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fa26j-0008T4-Pk
	for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 12:55:22 -0400
Received: from mail-wm0-f42.google.com ([74.125.82.42]:52322)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1fa26i-0008Sr-10
 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 12:55:20 -0400
Received: by mail-wm0-f42.google.com with SMTP id w16-v6so9090758wmc.2
 for <32034 <at> debbugs.gnu.org>; Mon, 02 Jul 2018 09:55:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=Mj9oOOlMCVai30SecQF94ZZXFKAlrbRga7FIT2j50I0=;
 b=awEZi22aHtV5nPcHjx5rrii57uuAMX+N8BvdNZ7/adlIRPWrLQGNdXHDOqohkB7EE2
 sLamsyIcIyx70Sb7JRHb4BGsd+22R0tuzsgPd5qwmsZg6SS2idwTLysY1J6lR1MbvtWs
 uob6zVvFSaYmd+AiQQnnXM5kBP0i4UbtEzJ5DJotq5QRtkiiHSa5Q9qVQoY2ZVxukFKy
 BtHqb/OdfdDBLkiTo382fuPHM7AJwOm0f0VOzqH8I0fY9keDK98dU+c1vRFfTUkZTJjQ
 ziGhdnegL8BoCu4MLCrye46soOkdUnnUTnySUrio2Ar2700dqRzZI9YY2JvkA7uy7E02
 mcyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=Mj9oOOlMCVai30SecQF94ZZXFKAlrbRga7FIT2j50I0=;
 b=K1RLPG72YPFLxl2/lwyDrsR4lfDQm2cJGMkkTcdtVyzFt6KcIlq1z5Xsq9P+ag4/ts
 20o95ERJEaXSlwLPHAQ1e/8KKrcakjBmLHIWWEctxcoVqGsZ1cKjhYw7LgA4WdamHFSE
 ZTPD8+HBYVtJ+jH+oAUP8c8X6gc34MLw+25vOpw/O5ZvJW8Y9h/6VfJa3ymLpwqXzaa4
 fB+KL4AHX75Rbc/YCpB3NcCvaREw1ynmtHG8lfSjDPDWCIwTx0vYj4HKwh5veO3sOlsd
 xV2QPz0nWP/zuVgz3H2S1z0gze60Qd2OJGxWcvVKJQh5YH+NBmLdXYpCPaZdIoUektMS
 usNg==
X-Gm-Message-State: APt69E0SSrlTy223EO1x3lHw9ljaugeeulCDRTp3sN15OsX0KPhpCUdl
 /uOL+uVSKP23qKWT6M45RSU=
X-Google-Smtp-Source: AAOMgpcNRvVUzP9CP62h0rM04OFzx0JV3kTPrWwJARRp8FMmhYDHw9wvPv0+YwH9cspsMOxgMvXarw==
X-Received: by 2002:a1c:b484:: with SMTP id
 d126-v6mr8740869wmf.17.1530550514160; 
 Mon, 02 Jul 2018 09:55:14 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
 [94.62.139.188])
 by smtp.gmail.com with ESMTPSA id r2-v6sm12839369wmb.39.2018.07.02.09.55.13
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Mon, 02 Jul 2018 09:55:13 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
 <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN>
 <87bmbpskl8.fsf@HIDDEN> <83muv9k38v.fsf@HIDDEN>
Date: Mon, 02 Jul 2018 17:55:09 +0100
In-Reply-To: <83muv9k38v.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 02 Jul
 2018 19:32:16 +0300")
Message-ID: <87o9fpfuhe.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.1 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Eli Zaretskii writes: >> From: joaotavora@HIDDEN (=?UTF-8?Q?Jo=C3=A3o?=
    =?UTF-8?Q?T=C3=A1vora?=) >> Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN >> 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). [...] 
 
 Content analysis details:   (1.1 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                             trust
                             [74.125.82.42 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (joaotavora[at]gmail.com)
 -0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3)
                             [74.125.82.42 listed in wl.mailspike.net]
  0.1 FROM_EXCESS_BASE64     From: base64 encoded unnecessarily
  0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
 -0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
  1.0 FREEMAIL_REPLY         From and body contain different freemails
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: joaotavora@HIDDEN (Jo=C3=A3o T=C3=A1vora)
>> Cc: 32034 <at> debbugs.gnu.org,  dgutov@HIDDEN
>> Date: Mon, 02 Jul 2018 16:50:27 +0100
>>=20
>> > 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.=20=20

>
>> 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=20
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=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Jul 2018 17:31:02 +0000
Resent-Message-ID: <handler.32034.B32034.15305526233258 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org, dgutov@HIDDEN
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.15305526233258
          (code B ref 32034); Mon, 02 Jul 2018 17:31:02 +0000
Received: (at 32034) by debbugs.gnu.org; 2 Jul 2018 17:30:23 +0000
Received: from localhost ([127.0.0.1]:43873 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fa2ed-0000qT-D7
	for submit <at> debbugs.gnu.org; Mon, 02 Jul 2018 13:30:23 -0400
Received: from eggs.gnu.org ([208.118.235.92]:58517)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1fa2eb-0000qH-Fx
 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 13:30:21 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1fa2eV-0003SX-K2
 for 32034 <at> debbugs.gnu.org; Mon, 02 Jul 2018 13:30:16 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33181)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1fa2eM-0003E8-UL; Mon, 02 Jul 2018 13:30:06 -0400
Received: from [176.228.60.248] (port=1388 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1fa2eM-0001QX-1N; Mon, 02 Jul 2018 13:30:06 -0400
Date: Mon, 02 Jul 2018 20:29:53 +0300
Message-Id: <83lgatk0ku.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87o9fpfuhe.fsf@HIDDEN> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Mon, 02 Jul 2018 17:55:09 +0100)
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
 <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN>
 <87bmbpskl8.fsf@HIDDEN> <83muv9k38v.fsf@HIDDEN> <87o9fpfuhe.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: João Távora <joaotavora@HIDDEN>
> Cc: 32034 <at> debbugs.gnu.org,  dgutov@HIDDEN
> Date: Mon, 02 Jul 2018 17:55:09 +0100
> 
> 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.

No.  I'm okay with your solution for 1 to go to emacs-26.  I had
reservations about your solution for 2, but now I understand it won't
affect the existing back-ends, so I'm okay with it on emacs-26, too
(but will probably suggest a clearer message text if Dmitry agrees
with the solution).

3 should indeed go to master.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 03 Jul 2018 13:57:01 +0000
Resent-Message-ID: <handler.32034.B32034.153062621330103 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, 32034 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153062621330103
          (code B ref 32034); Tue, 03 Jul 2018 13:57:01 +0000
Received: (at 32034) by debbugs.gnu.org; 3 Jul 2018 13:56:53 +0000
Received: from localhost ([127.0.0.1]:45573 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1faLnY-0007pT-On
	for submit <at> debbugs.gnu.org; Tue, 03 Jul 2018 09:56:52 -0400
Received: from mail-wm0-f54.google.com ([74.125.82.54]:38646)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1faLnX-0007pE-GP
 for 32034 <at> debbugs.gnu.org; Tue, 03 Jul 2018 09:56:51 -0400
Received: by mail-wm0-f54.google.com with SMTP id 69-v6so2381545wmf.3
 for <32034 <at> debbugs.gnu.org>; Tue, 03 Jul 2018 06:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:references:cc:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=2nHZHGSsVjz3jdWh/9qCSmgfeMer5Z01TW3MLX+rDkU=;
 b=dZn2QqgCIN/RkuvD13OgKR7Qf9pJwRCnage+sexlIs7KN+2oXWQqSqWG0hFOk4WeNZ
 Qotl+lpSxChWk77CvOPDfyMb1aNieemvsuOlibLqsK64jFHYTiv3N/3/Cg5aa7JkZoMR
 pbCOWLhwpP5LrzAFetybiY/uw//65crS3F+aCZmbOzxTFGtmF7ItYj3WgMHTCX/f/d/7
 Appoq4CpTNKgAJAWLAdbYepNw49xBxVkShLwLAPHXDu9Q/CNvt74fS3/Y+yG7e3SPCuv
 pnd3iMlIc1Ys1HDMkgFpMI8MzPADruQgsEgjkKsOMfyq9/ZutN0wPjUBHfNdc3vmmtf5
 UquQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:references:cc:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=2nHZHGSsVjz3jdWh/9qCSmgfeMer5Z01TW3MLX+rDkU=;
 b=lUSXBciIX7Ud30iQpsy2yICx0EW0yqC5qINdA8p/TvCXVYwKw/1XMgMflPsUcif/GY
 qGK1VkmLAtl72a2Vo3der3GKdCxwfKIIfyGdsX8pemmKAki3zFOlPMoutaxUg56mopnz
 frP6Dvntkhd+KQ7CQt8nYPbbNQmy36CU/0z8eCy3IMUGv39yf1nEmFsa0cMhsfZFAJMQ
 nr4LK3rPmDMByDh1yG1PYVnz40+1OpSU7CPWE7rZEJhLvvOjgugHWc1MYROX5p/PWlbW
 X4Z9fjEv2dLZz6HbG/ABcZZZSC+8diA5cBSbmRyVcuZ0Ovua81EpBTk4p/utG1lma7du
 n27w==
X-Gm-Message-State: APt69E3Z46FfB84JUpTUjwiTWdPksgtgATEhue8rRYH4YYra6nFYhpZS
 wp9hzw1nJW+983psORWB8mg=
X-Google-Smtp-Source: AAOMgpfQsws9E/bLu0h1N9kTEZ46CN+pISNPCsdwiZRMe0aFTnn6d2WUQVIpV43rAY2nQryMayNpnA==
X-Received: by 2002:a1c:4d09:: with SMTP id
 o9-v6mr8886637wmh.111.1530626205583; 
 Tue, 03 Jul 2018 06:56:45 -0700 (PDT)
Received: from [192.168.0.200] ([109.110.245.170])
 by smtp.googlemail.com with ESMTPSA id
 72-v6sm2217394wmo.26.2018.07.03.06.56.43
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 03 Jul 2018 06:56:44 -0700 (PDT)
References: <87y3etsqb7.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
Date: Tue, 3 Jul 2018 16:56:42 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <87y3etsqb7.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

Hi guys,

I've read up on the discussion.

On 7/2/18 4:46 PM, João Távora wrote:

> 1. xref-location-marker should check for `file-readable-p' before trying
> to open the file, and if that fails issues an error ("File %s can't be
> found.").

I'm fine with this, naturally.

> 2. if the file is found, xref-location-marker should detect if the
> location is indeed available in the file, and if it isn't, issue a
> message.  In that case it should return a marker to the nearest possible
> location.

When xref-location-marker is inaccurate, it may lead to problems, like 
xref-query-replace-in-results sometimes performing replacements at the 
"auto-corrected", wrong positions.

Maybe we can add a laxer version of this function that is only used when 
we know the user will be looking at the result directly (e.g. from 
xref-find-definitions, but not from xref-query-replace-in-results). I'm 
on the fence about xref-fined-references regarding this, because it also 
supports automatic replacement.

> 3. Number 2. could turn out to be brittle and annoying if we have
> changed the file in the meantime (but probably not more so than jumping
> to a wrong location).  So we could have a "hint" field in
> xref-file-location (or a xref-hinted-file-location) that helps in
> looking around the landing point for, say, a regexp, and puts point
> there.  Historically, this technique is successfully used in SLIME.  We
> could also reasonably default that field to the identifier being looked
> for.

I'm not sure this is a good idea. Certainly not the "defaulting to the 
identifier" bit. Because the identifier could e.g. look like 
namespace-name/symbol-name, where only "symbol-name" appears verbatim in 
the definition. I don't have much experience with LSP, but I imagine 
this could happen there, too (unless it only supports navigation to 
unqualified identifiers).

Now, if hint is optional (and disabled by default), and extracting the 
relevant code from Etags is natural, I say go for it.

But overall, I think individual backends that want "smarter" behavior 
should create their own "location" class, like Elisp does.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 03 Jul 2018 14:51:02 +0000
Resent-Message-ID: <handler.32034.B32034.15306294323721 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 32034 <at> debbugs.gnu.org
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.15306294323721
          (code B ref 32034); Tue, 03 Jul 2018 14:51:02 +0000
Received: (at 32034) by debbugs.gnu.org; 3 Jul 2018 14:50:32 +0000
Received: from localhost ([127.0.0.1]:45585 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1faMdU-0000xx-6C
	for submit <at> debbugs.gnu.org; Tue, 03 Jul 2018 10:50:32 -0400
Received: from mail-it0-f43.google.com ([209.85.214.43]:35642)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1faMdS-0000xj-4I
 for 32034 <at> debbugs.gnu.org; Tue, 03 Jul 2018 10:50:30 -0400
Received: by mail-it0-f43.google.com with SMTP id l16-v6so3528799ita.0
 for <32034 <at> debbugs.gnu.org>; Tue, 03 Jul 2018 07:50:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=BNOx+AL1/4CtB1fqlafL0W98C3+ETcs4sa98G3i1sLc=;
 b=qoBIcnjZA6f+feL0Vue8vVCowOq+xW8kivXJx4+tBJDKg8aH7rE8tmWrRp5ighifBq
 j0MKjjUhmvnjBgVLTkGBw1S4Pml846rjzQwquKZoZJqmDNtxCc5XnEG082fDsE0iW7gq
 aqnj6aF6kqFF8YEVyi1jwFt0dxDDlMgKLO4pIRg5i+ybcOkFN4G6R+7FhVROrNO+KiKs
 bZECctu13f9celH372OBjLhiMA9XHfGqn2zg5W2DPp7TqcbRQV/sNuVKiQ79ndQU1Vu4
 dbiDsoOJnPtiPwAH4Nr0sML+YUW+0ZTIfGbaXXOmWMqhPqsAeX9DUiW0CHuCCF08Sxhr
 mlhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=BNOx+AL1/4CtB1fqlafL0W98C3+ETcs4sa98G3i1sLc=;
 b=ba/cNMquI1gK9WtcXFUYhel5k1zTakBUtG6koNFHliWFlOwy6DPpK5og1vi9UYD4nJ
 pBKzcdEn9mga0781FnBA4I5qyOSqiQw3l4RlXylS7Yl/NozE0IEsB/SVhrkGAuWhE6nT
 49B5ExLB4BLEfBLzT+o6ZOCjT69uqXCZ2QcgaCRRzzJY/KHJBT9nAEwNk7Bj4bnRgL7C
 vlYRr/+NmBAcTeU+MFyliOOAkERdjEZx1m5hspHCPnhIZbt/X5qUbV2J7w4V7CINxDs7
 QtWQkRvCi23/cSanzSRcTXuLiOxsb8vdfaq39L0K/mxh1OdUXUSm/Bft0s9hbomfb5L9
 X6bQ==
X-Gm-Message-State: APt69E2jkjZom1Ki/orAnX20BDWshBUC7CwV+LMYG26kX9gdyhW11uoV
 B2NJW9zC8QK+Y+fkH6kzDfwaCwjmFyLS2czOHsM=
X-Google-Smtp-Source: AAOMgpclGgh179yuyBJ3p3ivGq53KPdBz23RORsBnVBMe3WBtooyDP1pBbnknl7vVLUtpGYlYPNt7ZKRcyIGEZVkcFA=
X-Received: by 2002:a24:a342:: with SMTP id
 p63-v6mr13658176ite.67.1530629424280; 
 Tue, 03 Jul 2018 07:50:24 -0700 (PDT)
MIME-Version: 1.0
References: <87y3etsqb7.fsf@HIDDEN>
 <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
In-Reply-To: <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 3 Jul 2018 15:50:05 +0100
Message-ID: <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000001df8c60570196fbe"
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

--0000000000001df8c60570196fbe
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 3, 2018, 14:56 Dmitry Gutov <dgutov@HIDDEN> wrote:

>
>
> When xref-location-marker is inaccurate, it may lead to problems, like
> xref-query-replace-in-results sometimes performing replacements at the
> "auto-corrected", wrong positions.
>
> Maybe we can add a laxer version of this function that is only used when
> we know the user will be looking at the result directly (e.g. from
> xref-find-definitions, but not from xref-query-replace-in-results). I'm
> on the fence about xref-fined-references regarding this, because it also
> supports automatic replacement.
>

Right, this should go into xref-goto-xref (or whatever it is called) or
xref-find-definitions.  Or scratched, if it's too much work, because it's
not terribly useful.

>
>
> > 3. Number 2. could turn out to be brittle and annoying if we have
> > changed the file in the meantime (but probably not more so than jumping
> > to a wrong location).  So we could have a "hint" field in
> > xref-file-location (or a xref-hinted-file-location) that helps in
> > looking around the landing point for, say, a regexp, and puts point
> > there.  Historically, this technique is successfully used in SLIME.  We
> > could also reasonably default that field to the identifier being looked
> > for.
>
> I'm not sure this is a good idea. Certainly not the "defaulting to the
> identifier" bit. Because the identifier could e.g. look like
> namespace-name/symbol-name, where only "symbol-name" appears verbatim in
> the definition.



In that special case we will do no worse than the current version, wouldn't
we? So still a win on my book. And to do better for languages which do
present this problem would take very little work, especially if we take
advantage of inheritance and eieio slot methods.


I don't have much experience with LSP, but I imagine
> this could happen there, too (unless it only supports navigation to
> unqualified identifiers).
>
> Now, if hint is optional (and disabled by default), and extracting the
> relevant code from Etags is natural, I say go for it.
>
> But overall, I think individual backends that want "smarter" behavior
> should create their own "location" class, like Elisp does.
>

At this point, I'm thinking of dismissing the whole thing, and voting to
deprecate xref-file-location entirely. Nobody uses it and Eglot will
probably use something else before this issue is solved.  It's a shame we
can't share code, but if we can't give a default class any kind of useful
behavior, we might as well not have this class in the first place.

>

--0000000000001df8c60570196fbe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On T=
ue, Jul 3, 2018, 14:56 Dmitry Gutov &lt;<a href=3D"mailto:dgutov@HIDDEN"=
>dgutov@HIDDEN</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><b=
r>
<br>
When xref-location-marker is inaccurate, it may lead to problems, like <br>
xref-query-replace-in-results sometimes performing replacements at the <br>
&quot;auto-corrected&quot;, wrong positions.<br>
<br>
Maybe we can add a laxer version of this function that is only used when <b=
r>
we know the user will be looking at the result directly (e.g. from <br>
xref-find-definitions, but not from xref-query-replace-in-results). I&#39;m=
 <br>
on the fence about xref-fined-references regarding this, because it also <b=
r>
supports automatic replacement.<br></blockquote></div></div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">Right, this should go into xref-goto-xref (o=
r whatever it is called) or xref-find-definitions.=C2=A0 Or scratched, if i=
t&#39;s too much work, because it&#39;s not terribly useful.</div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></b=
lockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><br>
&gt; 3. Number 2. could turn out to be brittle and annoying if we have<br>
&gt; changed the file in the meantime (but probably not more so than jumpin=
g<br>
&gt; to a wrong location).=C2=A0 So we could have a &quot;hint&quot; field =
in<br>
&gt; xref-file-location (or a xref-hinted-file-location) that helps in<br>
&gt; looking around the landing point for, say, a regexp, and puts point<br=
>
&gt; there.=C2=A0 Historically, this technique is successfully used in SLIM=
E.=C2=A0 We<br>
&gt; could also reasonably default that field to the identifier being looke=
d<br>
&gt; for.<br>
<br>
I&#39;m not sure this is a good idea. Certainly not the &quot;defaulting to=
 the <br>
identifier&quot; bit. Because the identifier could e.g. look like <br>
namespace-name/symbol-name, where only &quot;symbol-name&quot; appears verb=
atim in <br>
the definition.</blockquote></div></div><div dir=3D"auto"><br></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">In that special case we will do no w=
orse than the current version, wouldn&#39;t we? So still a win on my book. =
And to do better for languages which do present this problem would take ver=
y little work, especially if we take advantage of inheritance and eieio slo=
t methods.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I=
 don&#39;t have much experience with LSP, but I imagine <br>
this could happen there, too (unless it only supports navigation to <br>
unqualified identifiers).<br>
<br>
Now, if hint is optional (and disabled by default), and extracting the <br>
relevant code from Etags is natural, I say go for it.<br>
<br>
But overall, I think individual backends that want &quot;smarter&quot; beha=
vior <br>
should create their own &quot;location&quot; class, like Elisp does.<br></b=
lockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">At this=
 point, I&#39;m thinking of dismissing the whole thing, and voting to depre=
cate xref-file-location entirely. Nobody uses it and Eglot will probably us=
e something else before this issue is solved.=C2=A0 It&#39;s a shame we can=
&#39;t share code, but if we can&#39;t give a default class any kind of use=
ful behavior, we might as well not have this class in the first place.</div=
><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
</blockquote></div></div></div>

--0000000000001df8c60570196fbe--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 03 Jul 2018 15:09:02 +0000
Resent-Message-ID: <handler.32034.B32034.15306304855325 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.15306304855325
          (code B ref 32034); Tue, 03 Jul 2018 15:09:02 +0000
Received: (at 32034) by debbugs.gnu.org; 3 Jul 2018 15:08:05 +0000
Received: from localhost ([127.0.0.1]:45589 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1faMuS-0001Np-Qc
	for submit <at> debbugs.gnu.org; Tue, 03 Jul 2018 11:08:04 -0400
Received: from mail-ed1-f54.google.com ([209.85.208.54]:42332)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1faMuR-0001NL-EF
 for 32034 <at> debbugs.gnu.org; Tue, 03 Jul 2018 11:08:03 -0400
Received: by mail-ed1-f54.google.com with SMTP id g12-v6so1863131edi.9
 for <32034 <at> debbugs.gnu.org>; Tue, 03 Jul 2018 08:08:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=9AYBIU/HHPXSiBbXXIbfDgF/3TML1OTGwDVpO4/j14A=;
 b=kOXwmc5WKEPsypopmTWvby3eFG2VyHf7935FmdfccVuEuZNCcxNPPitnIhsmY2pL9a
 gADPcGQbHj3quU1DN+RnwZ2INdvITKMH2E/oAC0o7t46G1dG43Ad/oX2VR3W3oV/DTWq
 i5Fr+GrSc9wE0pZ8rwjClTKeo7wdJLBEcPzEsJaAf4/vY+Mg5KAQ83JJGmXUNMFFSQsb
 sKWt4j7NBb19Uk3UjRc/0q1qLMtc26STRIkl4lOGu+AtXxo7dVf+4TDxX/W+No1UF2Bz
 yvV0M7gqIcmhofXy3Fhd6oPC7hIxtkQw8dpW5OQR8Q449z+Cxg+9d/shBIFWn71CmmtL
 2UWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=9AYBIU/HHPXSiBbXXIbfDgF/3TML1OTGwDVpO4/j14A=;
 b=UvdHCcsO4t6b3wKDJyMDSGivyIncm0kGk8T/bEf5ql9xx0oxdvMPIHq7Ijny/cefHX
 frrcfSjlifdxsusMQUPi5mXZZ5Bd5RDhmEGmTDXsVUt95jQC5dbyN5djAFhTKS0dsedp
 7DKSZvHxy+Krye1HvjufBx5Qj3pxmk+hbkCP0HMY8q9zJxQ9FCiIaYrHUjkznX6JenB9
 ahrFVpXhSUmcbe4aPcc1NmZe0wG3bFHhjWy3jrknGaRM0zwS4Ic7ZkTm6JjRRjSFEOxn
 WiOJzX8S7BRxLZCcRiZ3VVpNMP1Et9p1nl24+9Cj/dhAHaTSSqQHrol5XszMkdZh35UN
 aXKg==
X-Gm-Message-State: APt69E2cyXjAfXielA8RcnEYIhIrET71IHpxaIfTHfN2mHncqYnDBc6U
 j1zpjXurP8kRT6vh3DdgdCiW3+D/
X-Google-Smtp-Source: AAOMgpcAI01tBT1rrKbjb9InxGkWq792yDBEhhPwKCJgiMbTYiOD/v7KXsGYVdXM4fc2gFIcWijV6A==
X-Received: by 2002:a50:93c5:: with SMTP id
 o63-v6mr28492696eda.311.1530630477475; 
 Tue, 03 Jul 2018 08:07:57 -0700 (PDT)
Received: from [192.168.0.200] ([109.110.245.170])
 by smtp.googlemail.com with ESMTPSA id
 z11-v6sm776576edq.71.2018.07.03.08.07.55
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 03 Jul 2018 08:07:56 -0700 (PDT)
References: <87y3etsqb7.fsf@HIDDEN>
 <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
 <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
Date: Tue, 3 Jul 2018 18:07:54 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 7/3/18 5:50 PM, João Távora wrote:

> Right, this should go into xref-goto-xref (or whatever it is called) or 
> xref-find-definitions.  Or scratched, if it's too much work, because 
> it's not terribly useful.

I'm sure it will be useful in some situations, I'm just not sure about 
the odds.

> In that special case we will do no worse than the current version, 
> wouldn't we?

We would.

Say, we're looking for clojure.core/cons, and the marker leads us to 
"(defn cons" (the example is largely made up). The code looks for 
clojure.core/cons, doesn't find it, and signals an error (will it?).

Or worse, searches around and finds a verbatim reference to 
clojure.core/cons in a docstring somewhere in that file, and returns 
*that* location.

> At this point, I'm thinking of dismissing the whole thing, and voting to 
> deprecate xref-file-location entirely. Nobody uses it and Eglot will 
> probably use something else before this issue is solved. 

Err, it is used: in xref--collect-matches-1. And through it, in 
xref-collect-matches and xref-collect-references.

> It's a shame 
> we can't share code, but if we can't give a default class any kind of 
> useful behavior, we might as well not have this class in the first place.

We could. As long as we don't default to the identifier, and the backend 
has to explicitly provide the hint, we could be fine.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 03 Jul 2018 15:44:01 +0000
Resent-Message-ID: <handler.32034.B32034.15306326268634 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.15306326268634
          (code B ref 32034); Tue, 03 Jul 2018 15:44:01 +0000
Received: (at 32034) by debbugs.gnu.org; 3 Jul 2018 15:43:46 +0000
Received: from localhost ([127.0.0.1]:45617 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1faNSz-0002FC-Lf
	for submit <at> debbugs.gnu.org; Tue, 03 Jul 2018 11:43:45 -0400
Received: from mail-it0-f46.google.com ([209.85.214.46]:32771)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1faNSy-0002Ey-2d
 for 32034 <at> debbugs.gnu.org; Tue, 03 Jul 2018 11:43:44 -0400
Received: by mail-it0-f46.google.com with SMTP id y124-v6so4084862itc.0
 for <32034 <at> debbugs.gnu.org>; Tue, 03 Jul 2018 08:43:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=BBQ4KUdSxvkCrZnV5xfLck+0OYfm+YWD6jsVF6iNGms=;
 b=JlfGEb5F1xsH5aDd4ORViHp4wI31X5fxVk2DYctWmqozv/hJd0lluLkgRTIE4/fdCy
 OyBkPRgoc+wU0bozfZ8suVcTtcfHGS6huPsAnR8T5RgDLC9mK5j2bkEdQh5EdELqoNB7
 aO93661O7Z1A1j4sYTG+q+Rgb6sI3yOa0/L86OWJkJYQegsqC+luRoCPfKuyCZDJOEvf
 A9m00luqFCyYlRbqh+wRr+Gt4YW0Dbq9B6QPDt8WWA6546TAiN3Or/ue6oSKC0FchdhK
 cyLduF2RgAGaocOVWzj+Ylc0A048fwUfQ2USaqRe1PI0iI+g5j1X7YEessGYn8aleqDe
 U6Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=BBQ4KUdSxvkCrZnV5xfLck+0OYfm+YWD6jsVF6iNGms=;
 b=Gt47ucrQg4i0AlE3u/8zivR85sHEV+KsqHA7I2fimNgNu3TPe43UOMN88TTZo0UgRY
 lUOrLjk5XbAtkPEsYBmvv3LlGm4dICTmECf7WUnYObmgt9AMjcllsTJ/+USvvY8dkN8/
 dbtYrT8BKFE9CkB9kg4ZalnZ8k7Hi7Qkve4mhdboVIVYn03NVm9b1nSEb1hMKtZKfIF/
 o4f+QqQfPAW0K7Y4jozkPdnAtETw+Ub7ET8q72Hrd4hwJ4tlXwhY2suglUD9Oh8pMbDQ
 VvMX2Wh6da7dFpn48l7aUMfoNrhOh4ATNu1mM9mnfc3lQTfA6+erzogdN3VeF5swrq2u
 VQ7g==
X-Gm-Message-State: APt69E285seeiQgy9lFTAt3wqj72lzuk+r02BaVyCSW79XMNJQubCEtn
 90zWlDAgbIPfcyWwG378PPuhldw4xw+F5EwcP6w=
X-Google-Smtp-Source: AAOMgpdFV8BZVTrQrxTilyR733gTlFb4yjdtiQOaco+wdxeROFztodrYpz2MXXsT9oQfNnZvvKq283/AQiJwewEwOhA=
X-Received: by 2002:a02:664b:: with SMTP id
 l11-v6mr25351830jaf.70.1530632618279; 
 Tue, 03 Jul 2018 08:43:38 -0700 (PDT)
MIME-Version: 1.0
References: <87y3etsqb7.fsf@HIDDEN>
 <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
 <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
 <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
In-Reply-To: <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 3 Jul 2018 16:43:26 +0100
Message-ID: <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000007e944805701a2d2d"
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

--0000000000007e944805701a2d2d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 3, 2018, 16:07 Dmitry Gutov <dgutov@HIDDEN> wrote:

> On 7/3/18 5:50 PM, Jo=C3=A3o T=C3=A1vora wrote:
>
> > Right, this should go into xref-goto-xref (or whatever it is called) or
> > xref-find-definitions.  Or scratched, if it's too much work, because
> > it's not terribly useful.
>
> I'm sure it will be useful in some situations, I'm just not sure about
> the odds.
>
> > In that special case we will do no worse than the current version,
> > wouldn't we?
>
> We would.
>
> Say, we're looking for clojure.core/cons, and the marker leads us to
> "(defn cons" (the example is largely made up). The code looks for
> clojure.core/cons, doesn't find it, and signals an error (will it?).
>

No, no error. Stays put. So no worse.

>
> Or worse, searches around and finds a verbatim reference to
> clojure.core/cons in a docstring somewhere in that file, and returns
> *that* location.
>

We could avoid that (particulary far fetched) case (and the string case) by
checking syntax.


> > At this point, I'm thinking of dismissing the whole thing, and voting t=
o
> > deprecate xref-file-location entirely. Nobody uses it and Eglot will
> > probably use something else before this issue is solved.
>
> Err, it is used: in xref--collect-matches-1. And through it, in
> xref-collect-matches and xref-collect-references.
>

Oh, I must have misgrepped then. Excuse my ignorance, but are these
grep-like tools? If so, they shouldn't ever suffer from the "outdated"
malaise, right?

>
> > It's a shame
> > we can't share code, but if we can't give a default class any kind of
> > useful behavior, we might as well not have this class in the first plac=
e.
>
> We could. As long as we don't default to the identifier, and the backend
> has to explicitly provide the hint, we could be fine.
>

I guess a new xref-hinted-location subclass would be the way to go, if not
too much work.  But still think we should do something by default that will
do just as bad on the worst case. And if we use a new subclass, we're
guaranteed that.

>

--0000000000007e944805701a2d2d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, =
Jul 3, 2018, 16:07 Dmitry Gutov &lt;<a href=3D"mailto:dgutov@HIDDEN">dgu=
tov@HIDDEN</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7/3=
/18 5:50 PM, Jo=C3=A3o T=C3=A1vora wrote:<br>
<br>
&gt; Right, this should go into xref-goto-xref (or whatever it is called) o=
r <br>
&gt; xref-find-definitions.=C2=A0 Or scratched, if it&#39;s too much work, =
because <br>
&gt; it&#39;s not terribly useful.<br>
<br>
I&#39;m sure it will be useful in some situations, I&#39;m just not sure ab=
out <br>
the odds.<br>
<br>
&gt; In that special case we will do no worse than the current version, <br=
>
&gt; wouldn&#39;t we?<br>
<br>
We would.<br>
<br>
Say, we&#39;re looking for clojure.core/cons, and the marker leads us to <b=
r>
&quot;(defn cons&quot; (the example is largely made up). The code looks for=
 <br>
clojure.core/cons, doesn&#39;t find it, and signals an error (will it?).<br=
></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">No,=
 no error. Stays put. So no worse.</div><div dir=3D"auto"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><br>
Or worse, searches around and finds a verbatim reference to <br>
clojure.core/cons in a docstring somewhere in that file, and returns <br>
*that* location.<br></blockquote></div></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">We could avoid that (particulary far fetched) case (and the=
 string case) by checking syntax.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; At this point, I&#39;m thinking of dismissing the whole thing, and vot=
ing to <br>
&gt; deprecate xref-file-location entirely. Nobody uses it and Eglot will <=
br>
&gt; probably use something else before this issue is solved. <br>
<br>
Err, it is used: in xref--collect-matches-1. And through it, in <br>
xref-collect-matches and xref-collect-references.<br></blockquote></div></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">Oh, I must have misgrepped=
 then. Excuse my ignorance, but are these grep-like tools? If so, they shou=
ldn&#39;t ever suffer from the &quot;outdated&quot; malaise, right?</div><d=
iv dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt; It&#39;s a shame <br>
&gt; we can&#39;t share code, but if we can&#39;t give a default class any =
kind of <br>
&gt; useful behavior, we might as well not have this class in the first pla=
ce.<br>
<br>
We could. As long as we don&#39;t default to the identifier, and the backen=
d <br>
has to explicitly provide the hint, we could be fine.<br></blockquote></div=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">I guess a new xref-hin=
ted-location subclass would be the way to go, if not too much work.=C2=A0 B=
ut still think we should do something by default that will do just as bad o=
n the worst case. And if we use a new subclass, we&#39;re guaranteed that.<=
/div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
</blockquote></div></div></div>

--0000000000007e944805701a2d2d--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Jul 2018 13:00:02 +0000
Resent-Message-ID: <handler.32034.B32034.153070914618723 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153070914618723
          (code B ref 32034); Wed, 04 Jul 2018 13:00:02 +0000
Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 12:59:06 +0000
Received: from localhost ([127.0.0.1]:46009 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fahNC-0004rv-2g
	for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 08:59:06 -0400
Received: from mail-ed1-f43.google.com ([209.85.208.43]:39704)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1fahN9-0004rJ-22
 for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 08:59:03 -0400
Received: by mail-ed1-f43.google.com with SMTP id w14-v6so3999511eds.6
 for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 05:59:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=yMUWW5s/+19vpbQmFQdNPFi4xKyHnxmzzfPxXSSo37Y=;
 b=bHunUl96TDQs0cUh7V+0Yf5GTCCYa8XsfNNSLW1mG9UVZ596MY0QdlhZPuM+PJIwQx
 KuwNzIpR3zuEIL07bOhqCO1/psa41AYKm6tgSAwGrxNc2Hc6th4DP5WSBHdqY2mmFf/8
 fJTQbsWdvOdaJAOe3FLwcomzRaMfVh1cKQ36npbjbWVbGzbcIwzW6NmJYNf/5W3Mscj5
 B2zDRtR9hLTK2yss8AIERTiF+fMce8DDhwpAeNPoovQe4lMRmlKrsAa6jN5rGbDnQP0G
 cdJjDnai4LukC5t2DR9eNBuE3Nosl6GIDfEsKZP6CSF5f5ZadvNafsqBqo+D7g7yqTAq
 L7SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=yMUWW5s/+19vpbQmFQdNPFi4xKyHnxmzzfPxXSSo37Y=;
 b=HMCRkeGi3f+Qz9yjBnjyKk5QMlfF2o0m+Mel5Joc0tKTk83RuF/lEKFJQSLCiZjXIH
 mY9eQ329+hQDTarXeQ+FR+H0JI57y3pAu7sDS+YAeeQMB0bYWp0nwVy4rSPUu+LePQfU
 dd32B5MdnlBUY+v3OK96eu++J8uQvnwSO0GUweGYsAq6yyUmx0UDasa3rKqQumQxozrG
 UGgdWMFy54es6sjAuY9T6DoALaeflfH8R09jbt0GkF0KF3+JcV76MZAUrZFuYIjkrQ+Y
 hedkFxcX0GQ3K6e2isw1Rly5fxBNOjYxf0MUojfGbmhTnQt11ru5BVmjB9I3o/j/NkhB
 SdfQ==
X-Gm-Message-State: APt69E3NHYCtnM0uHUHSthTmZrer6X2C29qe4A2ucg95mktNyjBdYKP3
 RjO/7Jc1iJqnt6TEku2b2X8SsU2g
X-Google-Smtp-Source: AAOMgpeTa7jkeNVXeyzfLANwA3k0b2PFl4JkB0vNfegE9h9Me28aVK6dlegcIrJ4ZzZr1VGF4AyLHw==
X-Received: by 2002:a50:a846:: with SMTP id
 j64-v6mr2648463edc.210.1530709136981; 
 Wed, 04 Jul 2018 05:58:56 -0700 (PDT)
Received: from [192.168.0.200] ([109.110.245.170])
 by smtp.googlemail.com with ESMTPSA id
 x11-v6sm4309783edb.39.2018.07.04.05.58.55
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 04 Jul 2018 05:58:55 -0700 (PDT)
References: <87y3etsqb7.fsf@HIDDEN>
 <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
 <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
 <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
 <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN>
Date: Wed, 4 Jul 2018 15:58:53 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 7/3/18 6:43 PM, João Távora wrote:

> No, no error. Stays put. So no worse.

If it doesn't find the qualified symbol name somewhere else verbatim.

> We could avoid that (particulary far fetched) case (and the string case) 
> by checking syntax.

I wouldn't say it's far-fetched. More importantly, it adds a non-obvious 
condition on how symbol names should be presented in the completion 
table. Even if this gun doesn't shoot most of the time.

Maybe it's not in a docstring, but in some macro definition, or passed 
verbatim in some other language construct. Maybe it's part of some other 
definition name (separate definitions for methods in C++ come to mind).

> Oh, I must have misgrepped then. Excuse my ignorance, but are these 
> grep-like tools? If so, they shouldn't ever suffer from the "outdated" 
> malaise, right?

Well, the grep results buffer can (and often does) live after the user 
has opened one of the search results and made a change there.

It can certainly become outdated if the user has added or deleted a 
couple of lines there.

> I guess a new xref-hinted-location subclass would be the way to go, if 
> not too much work.  But still think we should do something by default 
> that will do just as bad on the worst case.
"won't do"? I'm unclear on your meaning here.

I'm not sure we really need a subclass if a new optional field would 
work just as well. It might be shorter implementation-wise, too.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Jul 2018 13:39:01 +0000
Resent-Message-ID: <handler.32034.B32034.153071148822502 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153071148822502
          (code B ref 32034); Wed, 04 Jul 2018 13:39:01 +0000
Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 13:38:08 +0000
Received: from localhost ([127.0.0.1]:46030 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fahyx-0005qs-KX
	for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 09:38:07 -0400
Received: from mail-wm0-f51.google.com ([74.125.82.51]:38512)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1fahyv-0005qJ-4X
 for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 09:38:05 -0400
Received: by mail-wm0-f51.google.com with SMTP id 69-v6so5741455wmf.3
 for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 06:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=UbErWz8R3KnmzBJ5dI75VnDUI1ashHxr6OvT7783FA0=;
 b=WSLeq2e/9CU6aTY4ZYZz6fYKNaMijnrxFgGV1EAU93oWV4Bbx0hpCnTjVejc7cwQ/+
 L4UNNbOuvgEOZWJN6B4GgYHme+yrlyJVAqA2OQtk/jQsiDnMAgLt6qXemgb9pbPK+8VS
 9j7nEZyFoq2I8Tn475NV3IOVMxJL7GA081uB9w7xLR695hW6sCUAVTvZKhUmJNVH1dn8
 /HageWUUzG4vrgFWv0ZyfZAXxlyUESizypb/Va/1/E/tVqriWzOHhnVIW093/aCRJUDi
 QyEHLk/jUlv/DyUL3GWThLDdJmgP84hQqNe3uLRXkg2z4s8WvVms634Q8GzzOjhVmKyJ
 SmmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=UbErWz8R3KnmzBJ5dI75VnDUI1ashHxr6OvT7783FA0=;
 b=IaQy6Ep5rEbKaWny6J6LE/mbErVsgJu12yTU19putLQQKP4BGRyvEbKtY7/tD+4ZNA
 OjS0jhjkCISXYqDFyNfbf3X2GUEu9xiHyJBehVP4xRI78eEweWezMGJY1t0Oj0DEwDAs
 bG7qx9mfQueAbGF7Y/PJxa4ucM2rZriYPY1vk/QG1ZE5fvZYQGA0CzY7m9IpmLBEitWZ
 inp5BWAs9rGkzR9dBCtOm8s/uHXba2L06ibmRmw8kvk1LWr1Kfbn9VyE6tuaC36RdoI6
 5Jue1WJPxf/FTWYkthL06UYd+aqMmfrYvbNToSiO9/r4jgVA+rTwiVKty9Mn7hJzrHc4
 cBlg==
X-Gm-Message-State: APt69E3BrHyDpwZdxCcIIaVOVzErilAbQz9jrBHgx+BD0hu9953G5eDn
 X9f5ChTveAOeRNULpbN6IQ0AENks
X-Google-Smtp-Source: AAOMgpcYOs2JXKwzCRY4Enuth4MTjT0k1JNzoandHuM0u2wpO6+IlXPTfziHTmd54KwrlaV1mTnKxQ==
X-Received: by 2002:a1c:8010:: with SMTP id
 b16-v6mr1762814wmd.41.1530711479056; 
 Wed, 04 Jul 2018 06:37:59 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
 [94.62.139.188])
 by smtp.gmail.com with ESMTPSA id s200-v6sm8520154wmb.44.2018.07.04.06.37.57
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Wed, 04 Jul 2018 06:37:58 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87y3etsqb7.fsf@HIDDEN>
 <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
 <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
 <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
 <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN>
 <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN>
Date: Wed, 04 Jul 2018 14:37:55 +0100
In-Reply-To: <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN> (Dmitry Gutov's
 message of "Wed, 4 Jul 2018 15:58:53 +0300")
Message-ID: <8736wzf7f0.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 7/3/18 6:43 PM, Jo=C3=A3o T=C3=A1vora wrote:
>
> Maybe it's not in a docstring, but in some macro definition, or passed
> verbatim in some other language construct. Maybe it's part of some
> other definition name (separate definitions for methods in C++ come to
> mind).

Still better than failing randomly.  Especially if you hint that the
match was approximate (much like the way diff tell you about "fuzz").

Anyway, those totally hypothetic future users of the class could well
and polish the default behaviour if they decided it's worth it.

> It can certainly become outdated if the user has added or deleted a
> couple of lines there.

But then, in that case, isn't it much better to find an actual match
(and perhaps warn) than to land the user in nowhereland?

Sure it won't probably won't beat the etags backend in the percentage of
times it gets it right.  But that's a quantitative difference, not
qualitative.

> I'm not sure we really need a subclass if a new optional field would
> work just as well.

Because I want something with some default behaviour.  Behaviour that is
admittely half-decent, but nevertheless better than current behaviour.
But since you showed that xref-location-marker is used by your grep
substitute, I don't want to cause any regressions in its existing,
broken behaviour, whatever that may be exactly.

> It might be shorter implementation-wise, too.

This is how I imagine the implementation:

   (defclass xref-hinted-location (xref-file-location)
     ((hint :initarg :hint))))
=20=20=20=20
   (cl-defmethod xref-location-marker :around ((l xref-hinted-location))
      <...code to search around...>)

Compared to the "add optional field" approach, there would be about 1 extra=
 line,
the defclass one.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Jul 2018 14:34:01 +0000
Resent-Message-ID: <handler.32034.B32034.153071483428242 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153071483428242
          (code B ref 32034); Wed, 04 Jul 2018 14:34:01 +0000
Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 14:33:54 +0000
Received: from localhost ([127.0.0.1]:46825 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1faiqv-0007LS-TB
	for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 10:33:54 -0400
Received: from mail-ed1-f47.google.com ([209.85.208.47]:39538)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1faiqu-0007LF-7k
 for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 10:33:52 -0400
Received: by mail-ed1-f47.google.com with SMTP id w14-v6so4206467eds.6
 for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 07:33:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=4XZ3SjtZOnexdAtKFZTmvDvFw/vNw4xEb+uITWKyPhw=;
 b=OV6nKhR5L9KN0me+ndSV9jq/rVJtikImPEsdtDOO+T8h2t6KfvR7aWdMAx6MmqslVl
 63KlHU9NejQdTM5wu3Ts+FhR0B+UQdy0WqERri48DphvMmna71oyFz5ob00lKS5xBzSx
 YcC3Pwyon/6FoM6w9EWmRRY2NbnIT9uA+uoVZC1bKIqikWmJu5fKeRyn3XgE/dZuzf56
 LPPndqjM0hN2H+apzqEZBGgQWW25Qdz6dBep3VrFEK2a2T6aOGXbPj/V7+SS6Uc8VBvP
 c0i+NEuWeHzUsMbIDxakxqvmKUmV82Gg92L+Y1jPawCNT8D5X3dzLIMYo5tqrnDMjHOO
 cLJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=4XZ3SjtZOnexdAtKFZTmvDvFw/vNw4xEb+uITWKyPhw=;
 b=K5/mQPBiTPIZh8dKRbpRISBaXcb99XFt1evge4KKgnlvV74AJ8QaAGZDHySSv6kI7W
 7dmX0M0tpCRS3wBXvFk0yzRfc9bIRkBY+DvEVmS9ljOOuJ0LUllRkMRnbaN2in9U32BR
 7GccD+JN16FMKSV6nyzsShvA3/8j2Vi6yu+qKSXsCE1VnV4BGUiTA4SI7zT+SNIi+IcB
 Hv9sEHeRpG9CV3FMUl/QaJ3buMZJl0p3uN8xOFygeF2MGcEHKUxuZnx28Zb1aN+k3gUj
 /7LxpLuxe/wn1PT0+tSXiQocyojMx0XwbglC11WsFjC28qb0LwT/IAcNQKEPtfxBt1P1
 L+zA==
X-Gm-Message-State: APt69E1OJHCIIKqKrdZvdFfWzDjMpuhkt3OFjXq/OLDuYEOeYqQ6kC8J
 Td+gF7IEu8slhGms4BAjaciZU+7Q
X-Google-Smtp-Source: AAOMgpdvLR9NMsX9JtVxOp7C3EG+ZLMYhPSILd7mMRbjxzL85SwLxjsIy3dlaGwii5V73xHvxfDwug==
X-Received: by 2002:a50:b613:: with SMTP id
 b19-v6mr3006127ede.255.1530714826145; 
 Wed, 04 Jul 2018 07:33:46 -0700 (PDT)
Received: from [192.168.0.200] ([109.110.245.170])
 by smtp.googlemail.com with ESMTPSA id
 c21-v6sm1838714edr.78.2018.07.04.07.33.44
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 04 Jul 2018 07:33:45 -0700 (PDT)
References: <87y3etsqb7.fsf@HIDDEN>
 <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
 <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
 <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
 <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN>
 <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN> <8736wzf7f0.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <54af7707-12a6-4d89-de8d-b07ac626c898@HIDDEN>
Date: Wed, 4 Jul 2018 17:33:42 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <8736wzf7f0.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 7/4/18 4:37 PM, João Távora wrote:

> Still better than failing randomly.  Especially if you hint that the
> match was approximate (much like the way diff tell you about "fuzz").

The problem is it will "break" correct navigations sometimes.

> Anyway, those totally hypothetic future users of the class could well
> and polish the default behaviour if they decided it's worth it.

Suppose we use a new class. If the hint argument is mandatory, then 
there should be no problem: the backend explicitly asked for this behavior.

Similarly if xref-file-location grows a new optional field which 
defaults to nil.

>> It can certainly become outdated if the user has added or deleted a
>> couple of lines there.
> 
> But then, in that case, isn't it much better to find an actual match
> (and perhaps warn) than to land the user in nowhereland?

Yes. And in Grep results, it might be beneficial to use the new 
behavior. The code creating the locations will pass line's contents as 
the "hint" (and maybe we should make the hint a regexp, to be able to 
use the line-beginning and line-ending anchors). In that use case, 
though, it would be better to error out if the hint is not found.

I'm somewhat worried about what will happen if a hint misdetects a match 
anyway, and we're in many-automatic-edits land (such as 
xref-query-replace-in-results), but on the balance, it'll probably be 
better than the current behavior anyway.

Except for, err... lines with several matches on them. Not sure what to 
do about those. A special class, probably.

> Because I want something with some default behaviour.  Behaviour that is
> admittely half-decent, but nevertheless better than current behaviour.
> But since you showed that xref-location-marker is used by your grep
> substitute, I don't want to cause any regressions in its existing,
> broken behaviour, whatever that may be exactly.
> 
>> It might be shorter implementation-wise, too.
> 
> This is how I imagine the implementation:
> 
>     (defclass xref-hinted-location (xref-file-location)
>       ((hint :initarg :hint))))
>      
>     (cl-defmethod xref-location-marker :around ((l xref-hinted-location))
>        <...code to search around...>)
> 
> Compared to the "add optional field" approach, there would be about 1 extra line,
> the defclass one.

If we use an optional field, we could call ignore-errors around 
forward-char if that field is present (your proposal number 1).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Jul 2018 14:54:01 +0000
Resent-Message-ID: <handler.32034.B32034.153071602729953 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153071602729953
          (code B ref 32034); Wed, 04 Jul 2018 14:54:01 +0000
Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 14:53:47 +0000
Received: from localhost ([127.0.0.1]:46832 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fajAA-0007n3-L2
	for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 10:53:46 -0400
Received: from mail-wm0-f50.google.com ([74.125.82.50]:39880)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1fajA8-0007mp-Jk
 for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 10:53:45 -0400
Received: by mail-wm0-f50.google.com with SMTP id p11-v6so6119618wmc.4
 for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 07:53:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=xzqUnVIY90aAiaQ6hJvyouDoukqW8gRTiVLGHUoQflI=;
 b=Fk3l1tA5guP0hCKDGvj9ZhZCRGAjAi1QAawDAg1GF0+ztYvtkJjbl1Uz98c6EJl8Y4
 qxgwjL5LoXKcl3/PhKNKYyE8xeEgEFDxxCcj44hdgCq4BOh3EGyRBQWPtL83Or8Vbp8x
 6yAY1+wxeTBAGG9yb/0JgqTGwFp1qm02WvjgzKBV19aTXw8gULBewGd+qamN91ZZbrZr
 WH4g70Nl8q54eJuWrqSixjfPVVcXfTXmVtfH0RdM/lMpfSS3xrIGb1hbTaG7jKJYtI1F
 tZur8WvRLoMHPZFnhytkl50zfCafaiFNjtmW6ykvAAVnMfA9pkmUCkn0HgPrkm3bSmwz
 JHYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=xzqUnVIY90aAiaQ6hJvyouDoukqW8gRTiVLGHUoQflI=;
 b=B4/6wUY+leDWQG09Q/J/BtnGAu3ynRd9MDtuAc6SbVQ8rdu/dIqwc6szrVLIXfGobZ
 iw7wQsVLNgzqZPyIO0DsmS6jUwh6zP5u7CeTlnP2CLAUZZQPYEBioCDN7EorWq7PvmBE
 ZWldDzIUPnY1f+2lnGHGSOJB/AP2t6t4fH8aapWaChoz2gMXas5C0P6mkQXpKhPro+s0
 KaFVqo8sbA476YMInCvVhD/z1FbuFyIjz2KT2Qm6qFtLptNqUAeQaNgvqP/wlb4s2MWn
 ZVNH/kWua1h2lnN2wcChrBenIBj/gtWiCLbouKxY/819O5qZv5efawrHMY0yQ8RKxGAN
 vZyg==
X-Gm-Message-State: APt69E16e8F12JTygtmLDqOVCanvlpLJIJaswGA60n5TuqQZn/h0/hxl
 MRRDyv0X7XXLksz9AkOIqv5Hji+I
X-Google-Smtp-Source: AAOMgpciVPvhuFlo8KjTP1MkIiN2BHTAZGm3NCan0MajSFtYkBQJ6PosH0NB6HV3yYC+KlV3H/V4pQ==
X-Received: by 2002:a1c:e3d5:: with SMTP id
 a204-v6mr1798260wmh.20.1530716018560; 
 Wed, 04 Jul 2018 07:53:38 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
 [94.62.139.188])
 by smtp.gmail.com with ESMTPSA id b190-v6sm7476371wma.24.2018.07.04.07.53.37
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Wed, 04 Jul 2018 07:53:37 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87y3etsqb7.fsf@HIDDEN>
 <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
 <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
 <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
 <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN>
 <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN>
 <8736wzf7f0.fsf@HIDDEN>
 <54af7707-12a6-4d89-de8d-b07ac626c898@HIDDEN>
Date: Wed, 04 Jul 2018 15:53:35 +0100
In-Reply-To: <54af7707-12a6-4d89-de8d-b07ac626c898@HIDDEN> (Dmitry Gutov's
 message of "Wed, 4 Jul 2018 17:33:42 +0300")
Message-ID: <87po03dpcg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 7/4/18 4:37 PM, Jo=C3=A3o T=C3=A1vora wrote:
>
>> Still better than failing randomly.  Especially if you hint that the
>> match was approximate (much like the way diff tell you about "fuzz").
>
> The problem is it will "break" correct navigations sometimes.

I don't understand.  Will _successful_ navigation ever land me on a spot
where the identifier I looked for _isn't_ there?

>> Anyway, those totally hypothetic future users of the class could well
>> and polish the default behaviour if they decided it's worth it.
>
> Suppose we use a new class. If the hint argument is mandatory, then
> there should be no problem: the backend explicitly asked for this
> behavior.

Yes, we agree.

> Similarly if xref-file-location grows a new optional field which
> defaults to nil.

Only in this case it's more code in the backend, and repeated across
backends.

>>> It can certainly become outdated if the user has added or deleted a
>>> couple of lines there.
>>
>> But then, in that case, isn't it much better to find an actual match
>> (and perhaps warn) than to land the user in nowhereland?
>
> Yes. And in Grep results, it might be beneficial to use the new
> behavior. The code creating the locations will pass line's contents as
> the "hint" (and maybe we should make the hint a regexp, to be able to
> use the line-beginning and line-ending anchors). In that use case,
> though, it would be better to error out if the hint is not found.
>
> I'm somewhat worried about what will happen if a hint misdetects a
> match anyway, and we're in many-automatic-edits land (such as
> xref-query-replace-in-results), but on the balance, it'll probably be
> better than the current behavior anyway.
>
> Except for, err... lines with several matches on them. Not sure what
> to do about those. A special class, probably.

So it would be a good idea to have this in grep/xref grep results after
all?

>> Because I want something with some default behaviour.  Behaviour that is
>> admittely half-decent, but nevertheless better than current behaviour.
>> But since you showed that xref-location-marker is used by your grep
>> substitute, I don't want to cause any regressions in its existing,
>> broken behaviour, whatever that may be exactly.
>>
>>> It might be shorter implementation-wise, too.
>>
>> This is how I imagine the implementation:
>>
>>     (defclass xref-hinted-location (xref-file-location)
>>       ((hint :initarg :hint))))
>>          (cl-defmethod xref-location-marker :around ((l
>> xref-hinted-location))
>>        <...code to search around...>)
>>
>> Compared to the "add optional field" approach, there would be about 1 ex=
tra line,
>> the defclass one.
>
> If we use an optional field, we could call ignore-errors around
> forward-char if that field is present (your proposal number 1).

I don't fully understand this, but I just remembered that it's better to
have a separate class for another, probably more interesting reason.  We
should just make it a mix-in: that way, we can give "hinted" semantics
to existing location classes, not just xref-file-location.

Regarding ignore-errors, we should (quite independently of the remaining
discussion) first agree if xref-location-marker should be allowed to
error at all, and what should happen if it does.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Jul 2018 15:09:02 +0000
Resent-Message-ID: <handler.32034.B32034.153071690031328 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153071690031328
          (code B ref 32034); Wed, 04 Jul 2018 15:09:02 +0000
Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 15:08:20 +0000
Received: from localhost ([127.0.0.1]:46845 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fajOE-00089D-Jk
	for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 11:08:20 -0400
Received: from mail-ed1-f47.google.com ([209.85.208.47]:39252)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1fajOC-000890-OL
 for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 11:08:18 -0400
Received: by mail-ed1-f47.google.com with SMTP id w14-v6so4279669eds.6
 for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 08:08:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=qs1DyJzRhYEHXeSFsczP8ofTWa9S3D/JfcyNrXOzal8=;
 b=pfMB8l4nWh1cTSkSv20H9AL4ZYrbXfwEe79nZ1KdrGUz0YBPpZFF/ndeOt/KkPYDHw
 /QtmojJdRJi3n76h30B9jeYZQXSJnN/RVdxpAqnD5/rD9OO5SjsOcWqOkQ0ExQVrzad8
 VcwLdzHhNNNVuCvTAL/2wH49aoKxV7AHVfXjr5JqLIf9CjGJGQ+gJcFjd41rtpIEvsrc
 5KvZ1JGQa2HfBHMt9JEc5DnquapCeGjFVfpRDVEIB9uJ7x7NIaroShKBrBMy7ZeR5d+F
 UgA7shhG4QepVLiDQFUgx0BFTu6wp4I3gaL5MshDxjVlFESRjBNp2oKh1op0NPtvKerO
 zHZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=qs1DyJzRhYEHXeSFsczP8ofTWa9S3D/JfcyNrXOzal8=;
 b=UOl02VUbBnyn6y/Vt2eVaSiuKvGA1+pzqiFld+u0NUu9+YY8kDINBIYHtdoA6HgMJu
 Y0kHbWe9fK+DiSZFqy4bfrt0JUAi/HMMk27hHSYPRNG4x8zx5UjoAq0uSZh3cXZApqdm
 qj8dgsWlQ8B31JsTCYjFSgVmVmxKamg0eilYzYpfJj7UJX0yg3jVTZENdGcTct+bQiJc
 n/ZWwRCJF9UrLcKoHRL+8mIfbhl59+NHj2JOJw74VB29EDO91IrxbMcnMVRxNJ6FLqwl
 M5mzVqQivh8xlqHs0y6RO/RkoAJj0L6FgrWBj1ro3fRb/z99FrJN6DVWIysG6W2D5MzJ
 XYbQ==
X-Gm-Message-State: APt69E1amEZzll9JyZjbiTU6AT0d/XrzEvWl8ECrXdTkEiioWWrhQTMo
 WeJz/j/IRah9TtzFQx6154hJzZoR
X-Google-Smtp-Source: AAOMgpdFcMbzLFtWnXDgYoAkNmEAkdpP3gAam/A5JSNlcQe90Ag4sqCQ3xY5ozw38DKK0dW8blOrPg==
X-Received: by 2002:a50:afa3:: with SMTP id
 h32-v6mr3116983edd.129.1530716890639; 
 Wed, 04 Jul 2018 08:08:10 -0700 (PDT)
Received: from [192.168.0.200] ([109.110.245.170])
 by smtp.googlemail.com with ESMTPSA id
 l4-v6sm2828039edk.53.2018.07.04.08.08.08
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 04 Jul 2018 08:08:09 -0700 (PDT)
References: <87y3etsqb7.fsf@HIDDEN>
 <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
 <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
 <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
 <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN>
 <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN> <8736wzf7f0.fsf@HIDDEN>
 <54af7707-12a6-4d89-de8d-b07ac626c898@HIDDEN> <87po03dpcg.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <7cb55086-b6c0-c7ad-d14b-fe3b81757452@HIDDEN>
Date: Wed, 4 Jul 2018 18:08:08 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <87po03dpcg.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

On 7/4/18 5:53 PM, João Távora wrote:

> I don't understand.  Will _successful_ navigation ever land me on a spot
> where the identifier I looked for _isn't_ there?

A similar string in the buffer, yes. But it might be not its definition.

Like in the example I made up, clojure.core/cons -> "(defn cons".

And I *do* think, when a hint is not found, the method should raise an 
error. This will be helpful for the search-replace functionality.

>> Similarly if xref-file-location grows a new optional field which
>> defaults to nil.
> 
> Only in this case it's more code in the backend, and repeated across
> backends.

Err, no? In particular, if the new code is in xref-file-location, any 
class inheriting from it could use it automatically. No need to repeat it.

> So it would be a good idea to have this in grep/xref grep results after
> all?

A good one, yes, but not so easily-implemented one.

>> If we use an optional field, we could call ignore-errors around
>> forward-char if that field is present (your proposal number 1).
> 
> I don't fully understand this, but I just remembered that it's better to
> have a separate class for another, probably more interesting reason.  We
> should just make it a mix-in: that way, we can give "hinted" semantics
> to existing location classes, not just xref-file-location.

It sounds useful, but I'm not sure how useful it's going to be in 
practice. E.g. elisp locations already have their own logic for that. 
Etags does, too.

And if another backend decides not to use xref-file-location, it will 
likely do so for reasons incompatible with this mixin's implementation too.

Anyway, if you'd like to propose a patch, that could be easier to discuss.

> Regarding ignore-errors, we should (quite independently of the remaining
> discussion) first agree if xref-location-marker should be allowed to
> error at all, and what should happen if it does.

I think it should.

   (cl-defmethod xref-location-marker ((l xref-bogus-location))
     (user-error "%s" (oref l message)))

is the canonical example.

And then xref-query-replace-in-results should catch them. I thought it's 
doing that already. :-(

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Jul 2018 19:18:01 +0000
Resent-Message-ID: <handler.32034.B32034.153073182429246 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.153073182429246
          (code B ref 32034); Wed, 04 Jul 2018 19:18:01 +0000
Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 19:17:04 +0000
Received: from localhost ([127.0.0.1]:46995 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fanGy-0007bd-J0
	for submit <at> debbugs.gnu.org; Wed, 04 Jul 2018 15:17:04 -0400
Received: from mail-wm0-f42.google.com ([74.125.82.42]:36564)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1fanGw-0007b6-Jx
 for 32034 <at> debbugs.gnu.org; Wed, 04 Jul 2018 15:17:03 -0400
Received: by mail-wm0-f42.google.com with SMTP id s14-v6so7465853wmc.1
 for <32034 <at> debbugs.gnu.org>; Wed, 04 Jul 2018 12:17:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=6+Ir8DBMkkbabpNrGowloL4t9eCo7TKYPlKgl0Cic98=;
 b=hhBln/JGeTjqWWKNNaUtYmLFAvZNq53HaeMvUrizZLJQowTyUovn2lUIqkbamVURjd
 hba67Qjhhq0EYTE7TyPrrQkw6+P5F19MvI0FduoiXD6xehr+lzZVQrINbcIK0cZcChSK
 pSJNeuhvPlqaz9kX0+FjzUCcv10cIELdUJ4TpXQtAWmgGe/11owXThAi6OPomb2fc0aV
 hthWPpkmswdYOPTCdP1QZLdJn+c9YydhjfbRtolKsOfprIJ0b0a9y0WM58nnWfp+9gIe
 MeNC11LUAWX9D7FgIYMyBKRBcWy1qJXiwOR4r1NpxEpC6UQtPQKcXL8i8A7yqtN4frS6
 ndUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=6+Ir8DBMkkbabpNrGowloL4t9eCo7TKYPlKgl0Cic98=;
 b=UBklbLM3Rcx/vXW0mX913vznONO+qWZFWUXRIeHtwqv38+p2++CiU2ezoFktvymdcX
 dOdhmFckyDHNyrr+LM9T51L9i7lm0rzhYrci+9+Bqzobxx2zJT6nnTGYQ0E/fwHRXe79
 J62Nuz0HqKbSRMyScXwPLSOiHP5liKbygIXsXiRjOMylZAwbil2ikOIIqSL5yAybN3j4
 JUts3u4ytkckhCsN+5ytorat61PFC4xpfLHT2sKwx2J9hhZDJ7xTisuHXaxoIALfzPuk
 jFVGUe1LaNs0Mid2AYsBbtOV67OqUf50Pd19kKD6HF4vuy4rt2WqgNV8T2KCdIQqCti9
 se5w==
X-Gm-Message-State: APt69E3xPa9iSF3cldZFHuboIhR688ZcH2WWlPhYHJNGbe06KXArA7Mo
 +u/dNaqqNCxjx1DXZOOZ+hN1Jif4
X-Google-Smtp-Source: AAOMgpcVtKdWEykqHT0akzHNEjN23Te8CPlFyGD5zIluKzI+Ha3GDRSUX0t5szm/7aZgDy16NnlOSw==
X-Received: by 2002:adf:e6d0:: with SMTP id
 y16-v6mr2604352wrm.35.1530731816459; 
 Wed, 04 Jul 2018 12:16:56 -0700 (PDT)
Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt.
 [94.62.139.188])
 by smtp.gmail.com with ESMTPSA id x6-v6sm5728905wrd.57.2018.07.04.12.16.55
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Wed, 04 Jul 2018 12:16:55 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87y3etsqb7.fsf@HIDDEN>
 <5ab17038-c13d-3dde-2db9-4bc9a1042235@HIDDEN>
 <CALDnm50Ed=8vAKCPJZUOYgKnZEuqg31-YDOT5VMYRQ1CNK53Fg@HIDDEN>
 <eb06fbb5-89e1-9cf4-2c1e-337f41ab6553@HIDDEN>
 <CALDnm52Ay=DTYebh1j=86E8=iminsn-UXkNMr+H-dbWYYrnP3w@HIDDEN>
 <f6298956-3a94-e48e-05a1-953e2b3894dd@HIDDEN>
 <8736wzf7f0.fsf@HIDDEN>
 <54af7707-12a6-4d89-de8d-b07ac626c898@HIDDEN>
 <87po03dpcg.fsf@HIDDEN>
 <7cb55086-b6c0-c7ad-d14b-fe3b81757452@HIDDEN>
Date: Wed, 04 Jul 2018 20:16:51 +0100
In-Reply-To: <7cb55086-b6c0-c7ad-d14b-fe3b81757452@HIDDEN> (Dmitry Gutov's
 message of "Wed, 4 Jul 2018 18:08:08 +0300")
Message-ID: <87lgaqerq4.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 7/4/18 5:53 PM, Jo=C3=A3o T=C3=A1vora wrote:
>
>> I don't understand.  Will _successful_ navigation ever land me on a spot
>> where the identifier I looked for _isn't_ there?
> A similar string in the buffer, yes. But it might be not its definition.
>
> Like in the example I made up, clojure.core/cons -> "(defn cons".

If this backend already exists, then I think it is flawed.  If it
doesn't, then it shouldn't be designed like this.  In a better design
xref-backend-identifier-at-point would return "cons", propertized with
some contextual information (in this case the fact that it belongs to
the "clojure.core/" namespace).

> And I *do* think, when a hint is not found, the method should raise an
> error. This will be helpful for the search-replace functionality.

Then maybe that functionality should bind some global variable to
control this behavior (in CL this would be done more elegantly with
restarts, but we don't have those yet).

>>> Similarly if xref-file-location grows a new optional field which
>>> defaults to nil.
>>
>> Only in this case it's more code in the backend, and repeated across
>> backends.
>
> Err, no? In particular, if the new code is in xref-file-location, any
> class inheriting from it could use it automatically. No need to repeat
> it.

We seem to be misunderstanding each other, and perhaps this is not so
important.  I merely meant that if the behaviour is not the default,
then backends will have to repeatedly activate it explicitly.
Simplistically, if the default behaviour were good enough for more than
50% of such backends, we're better off making it the default.

>> So it would be a good idea to have this in grep/xref grep results after
>> all?
>
> A good one, yes, but not so easily-implemented one.

Indeed, I don't fully understand what you have in mind.  But maybe
(actually hopefully) it could be implemented on top of my simplistic
approach.

>>> If we use an optional field, we could call ignore-errors around
>>> forward-char if that field is present (your proposal number 1).
>>
>> I don't fully understand this, but I just remembered that it's better to
>> have a separate class for another, probably more interesting reason.  We
>> should just make it a mix-in: that way, we can give "hinted" semantics
>> to existing location classes, not just xref-file-location.
>
> It sounds useful, but I'm not sure how useful it's going to be in
> practice. E.g. elisp locations already have their own logic for
> that. Etags does, too.

Yes, and it could/should be refactored to use the new mixin.  Also
you're ignoring stuff outside Emacs.  The main reason I'm interested in
this is, obviously, my own itch.  Which in this case is SLY and Eglot.
Both need locations and both need hinting.  Incidentally, SLY's ancestor
SLIME is where all this xref rubbish was lifted from in the first place
(mighty fine rubbish mind you :-)).

> And if another backend decides not to use xref-file-location, it will
> likely do so for reasons incompatible with this mixin's implementation
> too.

No.  Precisely the contrary.  In this proposal, the two classes are
independent so you needn't scratch one if you just don't like the other.
>
> Anyway, if you'd like to propose a patch, that could be easier to discuss.
>> Regarding ignore-errors, we should (quite independently of the remaining
>> discussion) first agree if xref-location-marker should be allowed to
>> error at all, and what should happen if it does.
>
> I think it should.
>
>   (cl-defmethod xref-location-marker ((l xref-bogus-location))
>     (user-error "%s" (oref l message)))
>
> is the canonical example.

Yes, but we have to agree how/if to unwind.  There are at least three
situations:

a) Error before the file is found (and buffer created)
b) Error after the file is found
c) No error

I think a) should always happen, but b) should only happen if a global
flag is bound (that seems to help your replacer, right?)

> And then xref-query-replace-in-results should catch them. I thought
> it's doing that already. :-(

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 10 Aug 2020 13:00:02 +0000
Resent-Message-ID: <handler.32034.B32034.159706436527179 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, dgutov@HIDDEN
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.159706436527179
          (code B ref 32034); Mon, 10 Aug 2020 13:00:02 +0000
Received: (at 32034) by debbugs.gnu.org; 10 Aug 2020 12:59:25 +0000
Received: from localhost ([127.0.0.1]:34890 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1k57Of-00074J-01
	for submit <at> debbugs.gnu.org; Mon, 10 Aug 2020 08:59:25 -0400
Received: from quimby.gnus.org ([95.216.78.240]:47428)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1k57Oc-000744-Lw
 for 32034 <at> debbugs.gnu.org; Mon, 10 Aug 2020 08:59:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID
 :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=U20Lmy8HHZCKmI/9L6luzVpZdKXppsfM03b5oAhKJJs=; b=BNxEIFV5yckZrHiJvtYlEsk5MU
 DHqTCdh2NtLQr3G+gElw/zJnkttH9zICcidqnUqaQcvujCCVDIDn8JyMgNO9TJpE7JcyrDQQh03Ny
 C+jHcrA47/+4Mc76cXXyXhz9k3J0jWbNAGnNyCdjH2oICD7dwFrByFcj76KROA10pspc=;
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo)
 by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1k57OR-00043I-Hc; Mon, 10 Aug 2020 14:59:15 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
 <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN>
 <87bmbpskl8.fsf@HIDDEN> <83muv9k38v.fsf@HIDDEN>
 <87o9fpfuhe.fsf@HIDDEN> <83lgatk0ku.fsf@HIDDEN>
Date: Mon, 10 Aug 2020 14:59:09 +0200
In-Reply-To: <83lgatk0ku.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 02 Jul
 2018 20:29:53 +0300")
Message-ID: <87zh724pya.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > No. I'm okay with your
 solution for 1 to go to emacs-26. I had > reservations about your solution
 for 2, but now I understand it won't > affect the existing back-ends, so
 I'm okay with it on emacs-2 [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

> No.  I'm okay with your solution for 1 to go to emacs-26.  I had
> reservations about your solution for 2, but now I understand it won't
> affect the existing back-ends, so I'm okay with it on emacs-26, too
> (but will probably suggest a clearer message text if Dmitry agrees
> with the solution).
>
> 3 should indeed go to master.

This was over two years ago, and there was some followup discussion
between Dmitry and Jo=C3=A3o, 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.

--=20
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 10 Aug 2020 18:54:02 +0000
Resent-Message-ID: <handler.32034.B32034.159708562630161 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Cc: 32034 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.159708562630161
          (code B ref 32034); Mon, 10 Aug 2020 18:54:02 +0000
Received: (at 32034) by debbugs.gnu.org; 10 Aug 2020 18:53:46 +0000
Received: from localhost ([127.0.0.1]:37508 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1k5Cva-0007qP-8W
	for submit <at> debbugs.gnu.org; Mon, 10 Aug 2020 14:53:46 -0400
Received: from mail-wr1-f49.google.com ([209.85.221.49]:42886)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1k5CvY-0007q8-89
 for 32034 <at> debbugs.gnu.org; Mon, 10 Aug 2020 14:53:44 -0400
Received: by mail-wr1-f49.google.com with SMTP id r4so9159563wrx.9
 for <32034 <at> debbugs.gnu.org>; Mon, 10 Aug 2020 11:53:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=dQA4L7Yu8fCzKKNn/NDAIRDltM/VimLCwfRuYM5tTD8=;
 b=WbTrsEl39JICPHtHcVRriT8H/mlGvaHFS+3Rv22/4ZsNwJEoltyO6nFH7//qlUcGoA
 bPXWf8+ppwfUCn1sUZ0Onyf3LrCKQbGamht2bNB4EL3pfHokfdWbMqb7yeAT6K6v9slo
 2JRLJCbUZ4fJd2N15OicoXcNjFXMpFdTgJ1+ohKHzj2c/Un1SYeIJTa55I+lOFqE9LnK
 dMdw5dt2h0ikyK+EEn/O+j5sc/MNsdeQppMaNVXpCg8Jv/59Q8M5SH/+tS34XqSzICR5
 yO/AcLOOMM6CX05YzgI6OYrdxdFoOKT8D4p/CSah9Ah5ILFup3rnv3i9If6VCpuC4Vrw
 G3rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=dQA4L7Yu8fCzKKNn/NDAIRDltM/VimLCwfRuYM5tTD8=;
 b=VEmqSN68FOEhDWhb5gVrxL0u01q/8NzFCK5bPD2ZPPYsWRlA9e6To1xBIz/V1eDjr4
 EtA5s1aWc2Zltqp/DPi5Zo6P7lmPZU0MaT691Lpx463npwOntsoVH23ZcAnnr2UUpzox
 6J3oqwVMHMWfYhFYfTYVP7pFqiThuoxVms/H1MCogfgWxhoeEBGkPB8/tcheH8eu0Ric
 XtqyO2hxQNEBqkaOaENHjTFAZNmKgRFiOUf/0/JSDK5y5gIo90aDI5vKUoMYeNAIH6J8
 cuY53gVIVQnpWjzHTxXyqXNru9L5XsvqM6v3o0tT5cm1onsaBdE3+sEm0heeiLA/OYl7
 zwxg==
X-Gm-Message-State: AOAM530/6olxUHwl7xYUghprPhCJFBYZy0OMoPFpnWObwIwTjLbCykBu
 4rz5GsCyiTjWF+yS/DFZ9Wq3TnjV
X-Google-Smtp-Source: ABdhPJwRERx/z5kLDF97af8KwIMJXujNwgSqtmNAq4xQUKe15CRmw8wSOfPIU5ICszS3n72MdZrZVQ==
X-Received: by 2002:adf:f44b:: with SMTP id f11mr2788287wrp.114.1597085614984; 
 Mon, 10 Aug 2020 11:53:34 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id p3sm698568wma.44.2020.08.10.11.53.33
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 10 Aug 2020 11:53:34 -0700 (PDT)
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
 <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN>
 <87bmbpskl8.fsf@HIDDEN> <83muv9k38v.fsf@HIDDEN>
 <87o9fpfuhe.fsf@HIDDEN> <83lgatk0ku.fsf@HIDDEN> <87zh724pya.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <e595ae8f-3826-4614-6834-87c7aab55539@HIDDEN>
Date: Mon, 10 Aug 2020 21:53:32 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87zh724pya.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On 10.08.2020 15:59, Lars Ingebrigtsen wrote:
> 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.

Nope, that wasn't the consensus.

The proposed patch had problems, and we haven't reached any next version.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 10 Aug 2020 20:43:01 +0000
Resent-Message-ID: <handler.32034.B32034.15970921508503 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 32034
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 32034 <at> debbugs.gnu.org, Helmut Eller <eller.helmut@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 32034-submit <at> debbugs.gnu.org id=B32034.15970921508503
          (code B ref 32034); Mon, 10 Aug 2020 20:43:01 +0000
Received: (at 32034) by debbugs.gnu.org; 10 Aug 2020 20:42:30 +0000
Received: from localhost ([127.0.0.1]:37589 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1k5Eco-0002D3-CM
	for submit <at> debbugs.gnu.org; Mon, 10 Aug 2020 16:42:30 -0400
Received: from mail-wr1-f46.google.com ([209.85.221.46]:42454)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1k5Ecl-0002Ci-Du
 for 32034 <at> debbugs.gnu.org; Mon, 10 Aug 2020 16:42:29 -0400
Received: by mail-wr1-f46.google.com with SMTP id r4so9416792wrx.9
 for <32034 <at> debbugs.gnu.org>; Mon, 10 Aug 2020 13:42:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=HxjkXTmUH35mYtAiV1SsVEmuyMTzSSOulqOSfRzULvQ=;
 b=OX+Cb/h/W3Xr1TWllENwQkMWSGMr+SZ5lEcDXljleTx2xSUTETWFAP12vfiGNhV8cH
 MH5LDiW9W7KoPSEu1Dn/Sw+QqoRt67kSPqm6VL0XMuPsLVRd9UHtTLmKPS5SUetFtsDq
 OMJnPla0FEE0D+DLUCfhvY3FbJi40hR9OQqaWWNDSKtr7Im8zzBcMRXou9eXxVSXrw7n
 D02wJW9tS3VaXtq4O6q0G5GXRnX9TMFbAqZkKsPtIFweAwwv+uALTLhbvZp0oqz6TrYs
 2M9Pqeja7quvIMSdnx6gWqYvSBxOFny52SouLx8k77AnYWy7+DKww4YKBcnSayqtQyE9
 9nbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=HxjkXTmUH35mYtAiV1SsVEmuyMTzSSOulqOSfRzULvQ=;
 b=t4ADDnwsnbCfinuQVZ8wNVZWk0+g7Hd+71fz/AAOPc/cBhiow6xNpzuPy2EpEyHIwE
 GYFWnRyAZ1kS1JS8HauPt/pmUzjjEzy7SGFym2G/KER9Uh6tRRkJlRfzYjYGq/Gm3xuy
 tcJmzJkUDQtyPoVblbWxRam3fzPHr01TjymsM6Q0RH+KTnaaR7z1iCBYgsrQJYRXW7/0
 rN6lBQmVjcRRBbn82koCE5CuMVEwNPR2mljEj26VQtOkvUAc96rqvVI63REtrJw9bdpl
 wZOFb9194Qcqa5VQofM0orralzlz4RRGPPTVejaQ6ofMkxOnsob4hXzqBz9GAc9igFwd
 5kPw==
X-Gm-Message-State: AOAM5321/TWH2t9E6ER6y5Ei64UKfekiy58krRLO6Zv6M5pHMXIswOUZ
 d6sFskoCKCF9ZyUzYCsN8ek=
X-Google-Smtp-Source: ABdhPJxCt4PObpwRDz60Aa6qrF5GHTDQd4DRP3Vbp8irf8Q4CDbZYBXhj3ot+DfYc2uifPLtruyALw==
X-Received: by 2002:adf:aa9e:: with SMTP id h30mr25170682wrc.377.1597092141314; 
 Mon, 10 Aug 2020 13:42:21 -0700 (PDT)
Received: from krug (89-180-144-39.net.novis.pt. [89.180.144.39])
 by smtp.gmail.com with ESMTPSA id b203sm1244415wmc.22.2020.08.10.13.42.20
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 10 Aug 2020 13:42:20 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87y3etsqb7.fsf@HIDDEN> <83601xlmno.fsf@HIDDEN>
 <87muv9sll6.fsf@HIDDEN> <83po05k5rx.fsf@HIDDEN>
 <87bmbpskl8.fsf@HIDDEN> <83muv9k38v.fsf@HIDDEN>
 <87o9fpfuhe.fsf@HIDDEN> <83lgatk0ku.fsf@HIDDEN>
 <87zh724pya.fsf@HIDDEN>
 <e595ae8f-3826-4614-6834-87c7aab55539@HIDDEN>
Date: Mon, 10 Aug 2020 21:42:18 +0100
In-Reply-To: <e595ae8f-3826-4614-6834-87c7aab55539@HIDDEN> (Dmitry Gutov's
 message of "Mon, 10 Aug 2020 21:53:32 +0300")
Message-ID: <87y2mm44id.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

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=C3=A3o, 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=C3=A3o

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 11 May 2021 13:41:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 11 09:41:32 2021
Received: from localhost ([127.0.0.1]:35444 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lgSdg-0000hI-Mz
	for submit <at> debbugs.gnu.org; Tue, 11 May 2021 09:41:32 -0400
Received: from quimby.gnus.org ([95.216.78.240]:47330)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1lgSdf-0000h3-9s
 for control <at> debbugs.gnu.org; Tue, 11 May 2021 09:41:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=y2DMZnmBBPlxezNTH1ekWJkRnbVzHV6CBxgePxRU/FA=; b=hdf81ZJLcSOvjdviLQtwWAEYIQ
 wUrgN0TMWHmmjD55m5kXomMMtwD9MUSv/va+yxqvu4vvI9AnrD/P2H/6XPGcXXO1dwkXHHaeUrvCs
 aBiCueVECAwR7RtgOqhwCJXT/C/aNSvxG8epjKwMzadEMZeVmwzKyGkBMjSt/NN3Toj0=;
Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1lgSdX-0005cU-JJ
 for control <at> debbugs.gnu.org; Tue, 11 May 2021 15:41:25 +0200
Date: Tue, 11 May 2021 15:41:23 +0200
Message-Id: <87r1idmlq4.fsf@HIDDEN>
To: control <at> debbugs.gnu.org
From: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: control message for bug #32034
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  tags 32034 - patch quit 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

tags 32034 - patch
quit

Last modified: Tue, 11 May 2021 13:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.