From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations Date: Tue, 3 Jul 2018 16:56:42 +0300 Message-ID: <5ab17038-c13d-3dde-2db9-4bc9a1042235@yandex.ru> References: <87y3etsqb7.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1530626108 8024 195.159.176.226 (3 Jul 2018 13:55:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Jul 2018 13:55:08 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 32034@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 03 15:55:03 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 1faLll-0001tl-94 for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2018 15:55:01 +0200 Original-Received: from localhost ([::1]:40700 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faLns-0003w2-I3 for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Jul 2018 09:57:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faLnk-0003sb-QU for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2018 09:57:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1faLni-0004aW-AM for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2018 09:57:04 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37676) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1faLni-0004aM-5V for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2018 09:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1faLnh-0007pq-OD for bug-gnu-emacs@gnu.org; Tue, 03 Jul 2018 09:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Jul 2018 13:57:01 +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.153062621330103 (code B ref 32034); Tue, 03 Jul 2018 13:57:01 +0000 Original-Received: (at 32034) by debbugs.gnu.org; 3 Jul 2018 13:56:53 +0000 Original-Received: from localhost ([127.0.0.1]:45573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1faLnY-0007pT-On for submit@debbugs.gnu.org; Tue, 03 Jul 2018 09:56:52 -0400 Original-Received: from mail-wm0-f54.google.com ([74.125.82.54]:38646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1faLnX-0007pE-GP for 32034@debbugs.gnu.org; Tue, 03 Jul 2018 09:56:51 -0400 Original-Received: by mail-wm0-f54.google.com with SMTP id 69-v6so2381545wmf.3 for <32034@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) Original-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) In-Reply-To: <87y3etsqb7.fsf@gmail.com> Content-Language: en-US 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:148152 Archived-At: 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.