From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: mctags Date: Thu, 12 Oct 2017 19:13:12 +0300 Message-ID: <83mv4wl4yv.fsf@gnu.org> References: <87h8v439ub.fsf@gmail.com> <837ew0mupm.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1507824882 31208 195.159.176.226 (12 Oct 2017 16:14:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Oct 2017 16:14:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: chen bin Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 12 18:14:38 2017 Return-path: Envelope-to: ged-emacs-devel@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 1e2g7t-0006I9-HU for ged-emacs-devel@m.gmane.org; Thu, 12 Oct 2017 18:14:25 +0200 Original-Received: from localhost ([::1]:46393 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2g80-000339-MP for ged-emacs-devel@m.gmane.org; Thu, 12 Oct 2017 12:14:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2g6x-00030y-NH for emacs-devel@gnu.org; Thu, 12 Oct 2017 12:13:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2g6u-0001A2-Ih for emacs-devel@gnu.org; Thu, 12 Oct 2017 12:13:27 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2g6u-00019t-FA; Thu, 12 Oct 2017 12:13:24 -0400 Original-Received: from [176.228.60.248] (port=4644 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e2g6t-0006MQ-Lz; Thu, 12 Oct 2017 12:13:24 -0400 In-reply-to: (message from chen bin on Fri, 13 Oct 2017 00:24:17 +1100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:219420 Archived-At: > From: chen bin > Date: Fri, 13 Oct 2017 00:24:17 +1100 > > - If there are multiple matches, you can filter the candidates in candidate window. I think xref-find-definitions, when it uses the etags back-end, already supports that, doesn't it? > - the tags file is automatically created in current project. Yes, but AFAICT, the package uses a somewhat naïve way of generating TAGS, in effect passing all the non-trivial file names to etags. Some projects might use more sophisticated methods, for example see what src/Makefile does in Emacs to tag both the Lisp and the C names of the Emacs primitives. > - if no match found, fallback to `mctags-grep` to grep in current project. So you should always found matched > string But the matches found this way are not necessarily definitions, they can be references. > - Improvement on performance (for example, ripgrep is automatically used as grep program if installed. GNU > grep is fallback grep program) Well, finding a tag via etags.el doesn't require Grep at all. > - tags file could be automatically updated when user save current file. Is this really a good idea? Updating TAGS means you need also revisit it, which could be a problem in some complex setups, when there's more than one tag table active at the same time. OTOH, etags.el is written in a way that makes frequent updates of TAGS unnecessary.