From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: xref-query-replace Date: Sun, 10 Jan 2016 19:02:53 +0300 Message-ID: <569280AD.4040801@yandex.ru> References: <8360z2ojqd.fsf@gnu.org> <56912C28.8010002@yandex.ru> <831t9qogl8.fsf@gnu.org> <569139D1.5040907@yandex.ru> <83y4byn0jx.fsf@gnu.org> <56916801.4040907@yandex.ru> <83twmmms49.fsf@gnu.org> <56916BEB.3040705@yandex.ru> <83r3hqmrap.fsf@gnu.org> <56916F25.9090403@yandex.ru> <83poxamqpb.fsf@gnu.org> <5691719D.4030308@yandex.ru> <83mvsem7nl.fsf@gnu.org> <5691D5FA.8040201@yandex.ru> <83d1t9mny4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1452441797 24748 80.91.229.3 (10 Jan 2016 16:03:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2016 16:03:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 10 17:03:13 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aIISW-0006vk-NV for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 17:03:12 +0100 Original-Received: from localhost ([::1]:47506 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIISV-00082S-P0 for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2016 11:03:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIISK-00082N-9l for emacs-devel@gnu.org; Sun, 10 Jan 2016 11:03:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIISG-0000al-86 for emacs-devel@gnu.org; Sun, 10 Jan 2016 11:03:00 -0500 Original-Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:35482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIISG-0000af-0g; Sun, 10 Jan 2016 11:02:56 -0500 Original-Received: by mail-lf0-x234.google.com with SMTP id c192so201236797lfe.2; Sun, 10 Jan 2016 08:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=HVNsXKU9EoS+bFg1q8lehf3Pi5FVZ88kdhWYHvtLgqE=; b=K6T9HcTGNqRmzGYidhSEaWw4dk8NfAVAQo05tL8Zq7/lBzvvs7LKUFkIFuyJdkOzRX MWu+uhV9OatgMsSIuosKgkXyBDShezPTT6G3eASWXjL6dsZTf+74UYd0iNbXVSUAm+G2 bHAJvnQDhkzH1GQfsMT3fjFKhts0w7VNkrg7VCh6Kj+dUeUgYJf4jr/LTFdj1ndZGPJp UbIRRLPSr2suFnm6TtE4GBrciH1nvG/31417hD9FXM0pR/PYXO+DT6hlNq7qEA7gXLs8 73EXu3sngtpBBGkgLxC2LIJT6WshC8/zUK44OhM+qYZIwq3+Obt4UAhbQZ1uufsvO/aj MFwQ== X-Received: by 10.25.44.205 with SMTP id s196mr26399739lfs.0.1452441774897; Sun, 10 Jan 2016 08:02:54 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id b135sm3168232lfe.28.2016.01.10.08.02.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Jan 2016 08:02:53 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Thunderbird/43.0 In-Reply-To: <83d1t9mny4.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197972 Archived-At: On 01/10/2016 06:52 PM, Eli Zaretskii wrote: > By "false positives" do you mean matches to text that isn't really a > reference to 'foo'? This command is interactive, so the user can > reject irrelevant matches and accept only the relevant ones. So I see > this issue as a less important one. We could even display a warning > about potential false matches when the command is invoked in such a > buffer. All that, just to make sure the user isn't confused by the command not being applicable in that kind of xref buffer? The they will remain subtly confused in other respects. Also note how you've skipped the more complex case: when the identifier-to-search is fully qualified (i.e. not a string that usually occurs in a buffer). > By contrast, having a command inexplicably fail in a buffer that looks > and feels exactly like another one, where the command does work, is a > worse problem, IMO. If you insist on leaving things as they are, be > prepared for bug reports. At least they'll see that this buffer is different somehow. And if we didn't manage to explain it better, well, maybe a user will have a better idea for naming things. >> To put it differently, neither etags, nor find-func.el provide the necessary information to create xrefs with match boundary information. > > The boundary information just makes the matches more accurate, but it > doesn't invalidate them, AFAIU. I don't mean "symbol boundary". "boundary information" = match starts at position 11 and ends at 21 Etags doesn't provide that. >> I just don't see what kind of collective name would be possble. >> >> Well, I wouldn't ask if I managed to come up with one. I don't see another way to resolve the issue, however. > > Then I guess it will remain unresolved. Too bad. In my head, I call them something like "general xrefs" vs. "matches xrefs". The latter contain the boundary information.