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: Sat, 9 Jan 2016 23:05:21 +0300 Message-ID: <56916801.4040907@yandex.ru> References: <8360z2ojqd.fsf@gnu.org> <56912C28.8010002@yandex.ru> <831t9qogl8.fsf@gnu.org> <569139D1.5040907@yandex.ru> <83y4byn0jx.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: 8bit X-Trace: ger.gmane.org 1452369949 872 80.91.229.3 (9 Jan 2016 20:05:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jan 2016 20:05:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 09 21:05:44 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 1aHzlf-0001XN-1i for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 21:05:43 +0100 Original-Received: from localhost ([::1]:42680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHzlb-0006XQ-0A for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2016 15:05:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHzlP-0006XI-A4 for emacs-devel@gnu.org; Sat, 09 Jan 2016 15:05:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aHzlM-0005XG-3i for emacs-devel@gnu.org; Sat, 09 Jan 2016 15:05:27 -0500 Original-Received: from mail-lf0-x22b.google.com ([2a00:1450:4010:c07::22b]:33480) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aHzlL-0005X5-Rq; Sat, 09 Jan 2016 15:05:24 -0500 Original-Received: by mail-lf0-x22b.google.com with SMTP id m198so47187299lfm.0; Sat, 09 Jan 2016 12:05:23 -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=ZTnmIk0iWhphw+SlajXI0dXavbBI3Kjsqsn5oSuwKO0=; b=BIsAS0kMYLjPL8eTsAKkuIujfv9i4acVUPdWfQ/SEY0NvYA4y0co/FofRUpf4g2Z8b uyO/TE2Vg1grJ1y8TztTgg7o/lMtfRF6bGYpGeLuWr9KanC0qD57AmdR5OnLcmoudExQ aFBQ/JKF2RjYJvoKRiFFUwrVK/551mQvwFw6+/TJPfv8gqtAcllbIVvBIMaClh1A4DAL 4H2QfRXOjVAY0FhlPCNt39HSyjC1rejewDejT3hvacrePOdYhFTt6PHsXlgcpZp114Lg ncdsjlKmrvEdLDnfGtnTR3hgDHjbYkXs7wtn94U6+EvK3DGgA42K6CCmLHxswrpeOUS3 AY1g== X-Received: by 10.25.159.9 with SMTP id i9mr37069028lfe.109.1452369923105; Sat, 09 Jan 2016 12:05:23 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id a3sm14208109lbp.21.2016.01.09.12.05.21 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jan 2016 12:05:21 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Thunderbird/43.0 In-Reply-To: <83y4byn0jx.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::22b 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:197921 Archived-At: On 01/09/2016 08:08 PM, Eli Zaretskii wrote: > I thought xref didn't use etags to deduce the symbol at point, but if > I was mistaken, so be it. xref-find-definitions doesn't use the "symbol at point" check. But if it did, the check would succeed: symbols "exist" within comments, too. > Then maybe we should do something about this. In etags? xref-find-definitions, when using the etags backend, uses the info from TAGS for this. > The results of the two commands look very similar, and both buffers > are under XREF mode. So I think this distinction is very confusing. > At the very least, 'r' in the buffer where the command will do nothing > but barf should not invoke the command. So if would be better to make `r' be bound in some buffers under XREF mode, and unbound in other ones that look very similar? Let's make a better error message instead (suggestions welcome!). > It's up to the user to decide whether this makes sense, I think. So > we could ask her for confirmation, and if given, could proceed anyway. I don't know how to make the warning both informational and general enough. Better limit the functionality here. There are technical reasons, too, for this to be hard: we don't ask xref backends to return "match" xrefs in xref-backend-definitions implementations. I expect it might be non-trivial for some backends. >> Try starting with xref-find-references (bound to M-?). > > When I do that from *scratch*, I get this unfriendly error message: > > Customize ‘semantic-symref-filepattern-alist’ for lisp-interaction-mode > > Can we please make this work by default from *scratch*? Will do.