From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: chen bin Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: mctags Date: Fri, 13 Oct 2017 12:39:54 +1100 Message-ID: References: <87h8v439ub.fsf@gmail.com> <837ew0mupm.fsf@gnu.org> <83mv4wl4yv.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1507858804 30752 195.159.176.226 (13 Oct 2017 01:40:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Oct 2017 01:40:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 13 03:40:00 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 1e2oxD-0007Jp-4z for ged-emacs-devel@m.gmane.org; Fri, 13 Oct 2017 03:39:59 +0200 Original-Received: from localhost ([::1]:47996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2oxK-0007fM-JF for ged-emacs-devel@m.gmane.org; Thu, 12 Oct 2017 21:40:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46906) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2oxD-0007f1-3D for emacs-devel@gnu.org; Thu, 12 Oct 2017 21:40:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2oxB-00026n-Im for emacs-devel@gnu.org; Thu, 12 Oct 2017 21:39:59 -0400 Original-Received: from mail-it0-x22d.google.com ([2607:f8b0:4001:c0b::22d]:52337) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e2ox9-00025Y-NR; Thu, 12 Oct 2017 21:39:55 -0400 Original-Received: by mail-it0-x22d.google.com with SMTP id j140so8942979itj.1; Thu, 12 Oct 2017 18:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=a4LpPbfkF+vu2zuENTSjJlRlOUxfNICosJElUeK/VSk=; b=muU8co46AL94yetomzK/FB2cr4pBQsXTAh+tNkh7oFrH9bRY+DQ49ZTvzdpE9wrzqK M5CBfuZYv30yKSZtHOvbx7cwyrs5+cd4WUAlBXGazpY4vOqWFGWQ9M6lqtePJmdJHdk3 vgtc0SLNcF6e3wpjAeGJHeTuQVnWZA+zSqYtSKKi3hxkyMyJffEbNydk0P2yBaMPwaEB PQir7ODGPLnaupHjR3Wt5PKW9fwU9P0hH/0PGSldYCunuwveYJVxaQM2ty07rHZmU33R J+wlqZyX9LmnOVoIqqK6+mlSwjCQMBEOjxq3WLaC9+XFWs8Zh9bfCG5/HiHc01C9y9BF lQGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=a4LpPbfkF+vu2zuENTSjJlRlOUxfNICosJElUeK/VSk=; b=uFXw5YYuYMM5cf+Xk27K1nc3P7xK512CIh+Sqbo86FRlrHa06JyarJ4+IVEBGF9gFV VPM1eCD8TU88YyJrqe8EhB40ZSKUWbe2pTky4ZlDcVh+xetdCFBpt1qEUe+DHOx9Y/i0 BnqgiPP+YBcMi2Cg6HB42lHnyGuzu/AcCYTu1DE9jjJcASQV5UNdVpG7rvtGwX0fJ3Y0 aUG3kNsDsKx4SPbj14ONqdhLreqnAm2u5q2ECH++w2HZxg6+e8SJZGNdOEVBPkXZJ3IT +72lJOUo2sllviBtYyZHBIWLzh0PMoMxYdM9LwHtOBMeacmvuDoAy7/wdpF7+MOg0f20 bsuA== X-Gm-Message-State: AMCzsaWfleywwQ2MsfRiaNXinFqkRx6ITyEKKGzXaj6GGNJ1qiBxYssX v8YWH5hAN4yw2SbIHRvNt3OFBMwZTbWR/KHf4BCNrg== X-Google-Smtp-Source: AOwi7QBUPG5Z8oVSuYZEOrZHK8Esn7qrWZ6xJB/t3IzJDMu3Mo/K8jjFwgsmP23A5eQNrYJBu3RS/nArWQR4TBMpHZo= X-Received: by 10.36.253.9 with SMTP id m9mr202836ith.105.1507858794595; Thu, 12 Oct 2017 18:39:54 -0700 (PDT) Original-Received: by 10.107.133.90 with HTTP; Thu, 12 Oct 2017 18:39:54 -0700 (PDT) In-Reply-To: <83mv4wl4yv.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::22d 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:219435 Archived-At: On Fri, Oct 13, 2017 at 3:13 AM, Eli Zaretskii wrote: >> From: chen bin >> Date: Fri, 13 Oct 2017 00:24:17 +1100 >> >> - If there are multiple matches, you can filter the candidates in candid= ate window. > > I think xref-find-definitions, when it uses the etags back-end, > already supports that, doesn't it? I've been using xref for some time. As I can see, it just gives your the list of matches in a buffer. It can't filter further with pattern or negative pattern or combination of patterns. For example, I can filter candidates in mctags with "keyword1\|keyword2 !keyword3" (matching either "keyword1" or "keyword2" but not keyword3) > >> - the tags file is automatically created in current project. > > Yes, but AFAICT, the package uses a somewhat na=C3=AFve way of generating > TAGS, in effect passing all the non-trivial file names to etags. Some Good question. For tags creation, mctags now focus on out of box userexperience (For example, by default, `*.o`, `*.elc` are ignored`). Extra option could be added to tweak ctags cli in the future. But it's totally fine if you use mctags only for code navigation and leave TAGS creation to other solutions. Please note mctags RESPECTS the existing tags file created by other solutions. mctags will NOT override existing TAGS created by other programs (Makefile, for example) without user's confirmation. > 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. > Please note mctags RESPECTS the existing tags file created by other programs. It's IMPOSSIBLE mctags will override existing TAGS created by other programs (Makefile, for example) without user's confirmation. >> - if no match found, fallback to `mctags-grep` to grep in current projec= t. So you should always found matched >> string > > But the matches found this way are not necessarily definitions, they > can be references. > If definition is found, the grep will not be called. One reason I need this is that the TAGS might not be updated for the latest code change yet. Please note the UI make user clear that by displaying message "NO tag found. Now you are seeing grep results" at the top of candidate window. >> - 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. Grep is called if and only if mctags-find-tag fails. It's a useful feature when TAGS is not updated yet. For example, when I'm focusing on coding, I run `M-x find-tag` but no matches found. I've to stop to ask myself: "What' wrong? Did I forget to add definition? Or TAGS is not updated yet? Should I wait for ctags to finish updating? Or should I manually restart ctags process?". I'm forced out of "Flow" status by a simple "No matches found" message because too many questions popup. But in mctags, we display "No tag found" message PLUS the grep results. So I don't need THINK, I just TAKE ACTION to filter grep results. In my practice, this is huge productivity boost. > >> - 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. Some people might preferring TAGS auto-updating instead of manually running ctags from time to time. Anyway, TAGS auto updating is not enabled by default. So it will not conflict with your current ctags/etags setup. You can safely use `mctags-find-tag` without any worries on conflicts with other packages. At minimum, we give the users an extra option to update TAGS. Users have freedom to choose between these options. mctags is especially newbie friendly. Open `mctags.el`, `eval-buffer`, then `M-x mctags-find-tag-at-point`, that's enough. You don't need even create TAGS file manually. --=20 help me, help you.