From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: mctags Date: Fri, 13 Oct 2017 09:42:32 -0400 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=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1507902190 26626 195.159.176.226 (13 Oct 2017 13:43:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Oct 2017 13:43:10 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 13 15:43:04 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 1e30En-0004xO-Hc for ged-emacs-devel@m.gmane.org; Fri, 13 Oct 2017 15:42:53 +0200 Original-Received: from localhost ([::1]:50388 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e30Eu-0006Tj-Rj for ged-emacs-devel@m.gmane.org; Fri, 13 Oct 2017 09:43:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55904) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e30Em-0006TW-7s for emacs-devel@gnu.org; Fri, 13 Oct 2017 09:42:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e30Eh-0007SH-Bl for emacs-devel@gnu.org; Fri, 13 Oct 2017 09:42:52 -0400 Original-Received: from [195.159.176.226] (port=36053 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e30Eh-0007QC-3b for emacs-devel@gnu.org; Fri, 13 Oct 2017 09:42:47 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1e30EU-0002iL-QE for emacs-devel@gnu.org; Fri, 13 Oct 2017 15:42:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 63 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:JU5sN4v0yQfA2IBcakzLkAr5HFA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:219454 Archived-At: > 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. We introduced xref to try and provide a uniform UI to all the various ways to get etags-like functionality. So we want to move *away* from UIs specific to a particular etags-like tool. So if you found xref insufficient, instead of a new package I'd much rather see either xref extended to cover your needs (or its etags backend extended if the missing functionality is in that backend, or a new xref backend if extending the current backend proves impractical). > For example, I can filter candidates in mctags with > "keyword1\|keyword2 !keyword3" (matching either "keyword1" or > "keyword2" but not keyword3) As Eli mentioned when looking for definitions, in most cases this sophistication should not be needed, but I'm sure there can be circumstances where it can make sense, and indeed it can make a lot of sense when looking for references (rather than definitions), so it would make sense to add such a filtering feature to xref. >>> - 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 > Good question. For tags creation, mctags now focus on out of box > userexperience (For example, by default, `*.o`, `*.elc` are ignored`). Auto-creation is good indeed (personally I'd favor including only the files which are version controlled, so as to reuse the .ignore info already setup by the user instead of hard coding things like *.o). I think it'd be good to add to etags.el the ability to auto-create TAGS file. > 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. The problem here is what happens if you use mctags *before* running "make tags", in which case mctags will not know that it should respect the (not-yet) existing tags file. So I think the better answer is to let the user teach etags.el how to create the TAGS file in such special cases (i.e. it can have a default system, based on *.o thingies or based on VCS data, but that can be overridden on a per-project basis, e.g. via .dir-locals.el). > Grep is called if and only if mctags-find-tag fails. It's a useful > feature when TAGS is not updated yet. Such a feature should fit into xref as well. > Some people might preferring TAGS auto-updating instead of manually > running ctags from time to time. Agreed. Adding that functionality to etags.el would be nice (obviously optional as well, since again it might depend on how we build the TAGS file and things like that). Stefan