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: Wed, 4 Jul 2018 18:08:08 +0300 Message-ID: <7cb55086-b6c0-c7ad-d14b-fe3b81757452@yandex.ru> References: <87y3etsqb7.fsf@gmail.com> <5ab17038-c13d-3dde-2db9-4bc9a1042235@yandex.ru> <8736wzf7f0.fsf@gmail.com> <54af7707-12a6-4d89-de8d-b07ac626c898@yandex.ru> <87po03dpcg.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 1530716834 26055 195.159.176.226 (4 Jul 2018 15:07:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2018 15:07:14 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 Cc: 32034@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 04 17:07:10 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 1fajN1-0006YD-V0 for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jul 2018 17:07:04 +0200 Original-Received: from localhost ([::1]:47686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fajP9-0006to-1F for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Jul 2018 11:09:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fajOz-0006s4-S0 for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 11:09:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fajOw-0003rZ-M8 for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 11:09:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38948) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fajOw-0003rT-Fr for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 11:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fajOw-0008AE-9d for bug-gnu-emacs@gnu.org; Wed, 04 Jul 2018 11:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Jul 2018 15:09: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.153071690031328 (code B ref 32034); Wed, 04 Jul 2018 15:09:02 +0000 Original-Received: (at 32034) by debbugs.gnu.org; 4 Jul 2018 15:08:20 +0000 Original-Received: from localhost ([127.0.0.1]:46845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fajOE-00089D-Jk for submit@debbugs.gnu.org; Wed, 04 Jul 2018 11:08:20 -0400 Original-Received: from mail-ed1-f47.google.com ([209.85.208.47]:39252) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fajOC-000890-OL for 32034@debbugs.gnu.org; Wed, 04 Jul 2018 11:08:18 -0400 Original-Received: by mail-ed1-f47.google.com with SMTP id w14-v6so4279669eds.6 for <32034@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) Original-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) In-Reply-To: <87po03dpcg.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:148189 Archived-At: 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. :-(