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 23:24:32 +1100 Message-ID: References: <87h8v439ub.fsf@gmail.com> <837ew0mupm.fsf@gnu.org> <83mv4wl4yv.fsf@gnu.org> <83zi8vjuxd.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1507897489 4513 195.159.176.226 (13 Oct 2017 12:24:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Oct 2017 12:24: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 Fri Oct 13 14:24:45 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 1e2z18-0000Mb-8h for ged-emacs-devel@m.gmane.org; Fri, 13 Oct 2017 14:24:42 +0200 Original-Received: from localhost ([::1]:50065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2z1F-00036w-OU for ged-emacs-devel@m.gmane.org; Fri, 13 Oct 2017 08:24:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2z13-00035U-Nk for emacs-devel@gnu.org; Fri, 13 Oct 2017 08:24:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2z12-0008Oc-Iq for emacs-devel@gnu.org; Fri, 13 Oct 2017 08:24:37 -0400 Original-Received: from mail-it0-x232.google.com ([2607:f8b0:4001:c0b::232]:51623) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e2z11-0008Nc-11; Fri, 13 Oct 2017 08:24:35 -0400 Original-Received: by mail-it0-x232.google.com with SMTP id o135so10388681itb.0; Fri, 13 Oct 2017 05:24:33 -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; bh=BTliZNsIRBrLuJzr9s04Hwvo69rEuhFsspESx6S2BAU=; b=OUH0HKWsdtPpxHfNxD8fyLNeWBal+h+YvydrcqCvKKFafu5uoMZnv1MtIPotIL3S61 DfGhg0MaUIvgtzGdOTM/Rht4ObB86hQdvsqc6U55pS9UBiz7vv2U+rTWQQgy7vr2JJlf Y7QRLXkqnIrVasiqXUtNpml4QWSz/WIu9qGFaKffNKI/IO2XmzyNEPexXpo6NEk1BZkl LdIAkXFVbkWe4oORXbbou1AhnP9bolz4I8kqVqPrFHmeOcDnL4pi3wTHqT3VFZal/U2e k43cmU2QlOHtg2IBeNMuFIHaSl7pFClDMjMK4o1GAdHtVmG9vD1Vcuvldk0cLiltD0JZ vKJA== 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; bh=BTliZNsIRBrLuJzr9s04Hwvo69rEuhFsspESx6S2BAU=; b=PDiSy9iaomhr/o8mxIEbfrLNRTbeFVguCixtAudj1HVkkLHjkGIc9ha4JiXwsnLatK ZDGMCsGysNWISYwSSOoiKaWKUcMDqsw6x8BQVv3OR8bm+YdAsKR7foA6TzjHMOLv2hPP OF2jvWxt+XKXau+0eCbYpyuoiLmQ1n4afll/BRnXCmTjLV3bD0YVbhBDzp8KlUEZnXKt rquokZ8jN1mzWo8QI5NujKEAuy6d2Y0aNPVnkZBs99Lbqtwi5XGZIEYgl1LTRVYpwTzW +eN3u7o31fLaZDU9oRCbCPwgBCxpFYoSWA3TiGMsuIq298qdi772O7JbKKCli1nPSFQY QbOQ== X-Gm-Message-State: AMCzsaWbPhABLgHppaA8bVtfgVtmWY1ZyfAh79qRrLopXDKQzQJ5f68f 0LIYrMkzlHKLZHi5S0cea4TBy6bXrYy5YQMmhuE= X-Google-Smtp-Source: AOwi7QA46e6m/YxuKwL+hVeSvrbFt3D2mJ3drPuSX/a9oC3+DYVEtYqQoLNeaDi06JNZxkWrAw/eh2udsWW28ERtqys= X-Received: by 10.36.217.206 with SMTP id p197mr2135170itg.45.1507897472738; Fri, 13 Oct 2017 05:24:32 -0700 (PDT) Original-Received: by 10.107.133.90 with HTTP; Fri, 13 Oct 2017 05:24:32 -0700 (PDT) In-Reply-To: <83zi8vjuxd.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::232 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:219452 Archived-At: In web front end development,there could be dozens of candidates. For example, in ReactJS development, `props.method1` could be defined in parent or sibling components. Each component corresponds to a independent JS files. So you might need filter a lot of candidates by js file name. Advanced filter is must have feature. In web front end development, new wheels are keep being invented. For example, consider css, We got css/less/sass/scss/postcss/styled-component, six planguages. So ctags should be very generic to extract tags from these languages/frameworks. `mctags` is targeting on web developers. It has different road map from `etags.el`. `mctags` tries to fuzzy match as many candidates as possible without considering precision at first stage. Then filter out the noise in second stage. I tested with my current project. Using same TAGS file, `mctags` will find more candidates than `xref`. Web developers need extra "noise" because our projects are usually mixture of at least four syntax (css, html, js, plus a language at server side, C#/Java/PHP ...).. Actual tag definition could exist anywhere. My impression is `etags.el` comply with the convention of C/Perl developers who might not understand what web developers really want. On Fri, Oct 13, 2017 at 7:47 PM, Eli Zaretskii wrote: >> From: chen bin >> Date: Fri, 13 Oct 2017 12:39:54 +1100 >> Cc: emacs-devel@gnu.org >> >> >> - 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? >> 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. > > The list is usually very short (most of the time, only one candidate), > so the need for sophisticated filtering is quite low. > >> 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. > > I understand. It just seemed to me that, if we ignore for the moment > the features for creating/updating TAGS, what's left is very little, > and its contribution to the existing functionality is minor. It > doesn't seem to justify a new package. > > Maybe a better way forward is to extend etags.el with a few optional > features. > > Anyway, these are just my opinions. I'd be interested to hear from > others. > > Thanks. -- help me, help you.