From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations Date: Tue, 3 Jul 2018 15:50:05 +0100 Message-ID: References: <87y3etsqb7.fsf@gmail.com> <5ab17038-c13d-3dde-2db9-4bc9a1042235@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001df8c60570196fbe" X-Trace: blaine.gmane.org 1530629494 13643 195.159.176.226 (3 Jul 2018 14:51:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Jul 2018 14:51:34 +0000 (UTC) Cc: 32034@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 03 16:51:30 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1faMeQ-0003Rj-48 for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2018 16:51:30 +0200 Original-Received: from localhost ([::1]:40878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faMgX-0006DL-DZ for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2018 10:53:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faMe2-0004Et-3x for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2018 10:51:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1faMdy-0007ok-WE for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2018 10:51:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37688) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1faMdy-0007oY-MF for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2018 10:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1faMdy-0000yk-CT for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2018 10:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Jul 2018 14:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32034 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 32034-submit@debbugs.gnu.org id=B32034.15306294323721 (code B ref 32034); Tue, 03 Jul 2018 14:51:02 +0000 Original-Received: (at 32034) by debbugs.gnu.org; 3 Jul 2018 14:50:32 +0000 Original-Received: from localhost ([127.0.0.1]:45585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1faMdU-0000xx-6C for submit@debbugs.gnu.org; Tue, 03 Jul 2018 10:50:32 -0400 Original-Received: from mail-it0-f43.google.com ([209.85.214.43]:35642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1faMdS-0000xj-4I for 32034@debbugs.gnu.org; Tue, 03 Jul 2018 10:50:30 -0400 Original-Received: by mail-it0-f43.google.com with SMTP id l16-v6so3528799ita.0 for <32034@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) In-Reply-To: <5ab17038-c13d-3dde-2db9-4bc9a1042235@yandex.ru> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:148153 Archived-At: --0000000000001df8c60570196fbe Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018, 14:56 Dmitry Gutov 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

On T= ue, Jul 3, 2018, 14:56 Dmitry Gutov <dgutov@yandex.ru> 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 (o= r whatever it is called) or xref-find-definitions.=C2=A0 Or scratched, if i= t'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 jumpin= g
> to a wrong location).=C2=A0 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.=C2=A0 Historically, this technique is successfully used in SLIM= E.=C2=A0 We
> could also reasonably default that field to the identifier being looke= d
> 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 verb= atim in
the definition.


In that special case we will do no w= orse 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 ver= y little work, especially if we take advantage of inheritance and eieio slo= t 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" beha= vior
should create their own "location" class, like Elisp does.

At this= point, I'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's a shame we can= 't share code, but if we can't give a default class any kind of use= ful behavior, we might as well not have this class in the first place.