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: [Emacs-diffs] emacs-25 f8208b6: Document the user-level features of the Xref package Date: Thu, 21 Jan 2016 06:28:51 +0300 Message-ID: <56A05073.5090100@yandex.ru> References: <20160109191428.26341.44105@vcs.savannah.gnu.org> <5691C9D2.7080905@yandex.ru> <83egdpmo1j.fsf@gnu.org> <56929D6F.2050508@yandex.ru> <834melmfa4.fsf@gnu.org> <5692B1E0.8010100@yandex.ru> <831t9pma4e.fsf@gnu.org> <5693FDFA.2070607@yandex.ru> <83ziwbkj5l.fsf@gnu.org> <5694055E.6050201@yandex.ru> <83si1udcaz.fsf@gnu.org> <569D64AC.1060606@yandex.ru> <83powxbh6c.fsf@gnu.org> <569EB04F.800@yandex.ru> <8337tsc133.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 1453346963 23890 80.91.229.3 (21 Jan 2016 03:29:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Jan 2016 03:29:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 21 04:29:14 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 1aM5vt-0000Iz-3q for ged-emacs-devel@m.gmane.org; Thu, 21 Jan 2016 04:29:13 +0100 Original-Received: from localhost ([::1]:45880 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM5vs-0007go-Eb for ged-emacs-devel@m.gmane.org; Wed, 20 Jan 2016 22:29:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47782) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM5ve-0007gc-22 for emacs-devel@gnu.org; Wed, 20 Jan 2016 22:28:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aM5va-0004VQ-SL for emacs-devel@gnu.org; Wed, 20 Jan 2016 22:28:57 -0500 Original-Received: from mail-lb0-x22b.google.com ([2a00:1450:4010:c04::22b]:32890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM5va-0004VM-Fa; Wed, 20 Jan 2016 22:28:54 -0500 Original-Received: by mail-lb0-x22b.google.com with SMTP id x4so16366163lbm.0; Wed, 20 Jan 2016 19:28:54 -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=nOoaqGq2Qu6aT8H9wcHmM/5yYEeDNVREQrEWTuek1+A=; b=zE6L8D5ZsCnWTQmR2e8BarFxOC5Gg8VW8ei1b3AqdPPrhabMey2Vv0/F2MhkfQnFcR Qh34aP50QFvjGeZbULDt8ABjHj/2U+2oTSxPWFFJ/lukZjiGHScnfAF35VKqY5arHyXm 6mLPDKdgqr5JXdAHWJNfG0xu2JHmfM+sqMbnSy6AkeKgbRgRtAMH57/FkXHI851VkW8r EbqiF72ESDV0dfEq0EPTZPs0Jxpq+nC6Pi9OYTqn0Csc5Yo1aa+z6b8xjKFGMRnRq/aq 7/a8FS+1EhpCjBrjzYWe011nzXhsWeulzAI+MpG343HgplnJCvaQ/2FD9IGCOyEhab6c uWGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=nOoaqGq2Qu6aT8H9wcHmM/5yYEeDNVREQrEWTuek1+A=; b=U4XaAGOjpp8BnRW0lZZcCNytI16WGUHtOrOaazB+g37KtogQMPE0P3g0n9toSZ1IBp d+FWdE0aG7cwOfjoKuBH4BIvOYvhJ3njJg5oJAEN3KzxiJipUfj3NkhAssO+8xeBC3lp 6G8eShDRVrho+/oVWSjtCZvVjlZiqz5+Jg5xnwjEbHxbrQ/25aompU6vjcsb5jv/iYeM /4MVxfbXqqco5w4X1AGZUCj99jbbUo2ZiW4LGUlKuHRzbyst/4+MbcFfBUtIDCAr42Ds GFrqcFXiOF2c+zls5VQ3TUrrAaMPSt8IzPH4ZYAoHQeXo+89TfDHWMD4TlcKsEhDQCAV MuiQ== X-Gm-Message-State: ALoCoQkyODkRs5BpUhTwc+DYvn6hWoKZz3H9463uCOibg4TtjNimdaNm5zXbR4k+umZcGZCGJ4t5PORlYGutLXmT0sw/aqVhBg== X-Received: by 10.112.161.10 with SMTP id xo10mr14264577lbb.131.1453346933415; Wed, 20 Jan 2016 19:28:53 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id l129sm5102859lfl.37.2016.01.20.19.28.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 19:28:52 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <8337tsc133.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:c04::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:198485 Archived-At: On 01/20/2016 07:43 AM, Eli Zaretskii wrote: > "Xref" is the name of the node, not of the section. And the node's > name does not mean it describes xref the package; this is user-level > documentation. If you have a better suggestion for a short name of a > node which aims at describing features most of which have "xref-" in > their names, please tell. Cross-Referencing? A native speaker might have a better suggestion. > AFAICT, your additions are not directly related to this section; they > are not mentioned in it. Hmm. When I asked what we needed to obsolete tags-loop-continue, you only mentioned Dired commands. http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg00842.html > No, dired-do-find-regexp cannot replace it, because it looks through > all the files in the directory, whereas tags-search looks in the files > recorded in the tags tables. Ok, dired-do-find-regexp cannot. What about project-or-external-find-regexp? By default, when the VC project backend is used, and project-vc-external-roots-function is at its default value, project-or-external-find-regexp will search the current project, as well as the directories of the tags tables, if they are outside of it. Or, in emacs-lisp-mode, it will search the load-path directories. > We should have an xref-based replacement > for tags-search and tags-query-replace, which would similarly search > through the "relevant" files. tags-query-replace? We have xref-query-replace already, and it's more flexible: depending on which results it's called from, it'll perform replacements in simple regexp matches, or in "smarter" list of references (or other similar kinds of results). Back to tags-search. Like described above, we have a command that goes further that it already. So what would be the goal of having xref-find-regexp? Just to tick off a box and simplify updating the manual? It will require adding a new method to xref backends, with clear semantics and purpose. Backend authors will want to know why they implement it, and why a user might want to use xref-find-regexp, instead of the aforementioned alternative. Suppose we're in emacs-lisp-mode. What will xref-find-regexp do? Will it search the load-path elements, but skip the current project, however it's defined, if it's not in load-path? Will it only search *.el files inside load-path directories, and ignore files with all other extensions? > (Btw, I think replacing tags-search and tags-query-replace with > commands that start with "project-" is not a good idea, for the same I definitely never suggested replacing tags-query-replace with project- anything. The new "replace" workflow is two-step: two the search (using some command that creates an xref buffer), then call xref-query-replace.