Re: [ELPA] New package: mctags

[chen bin]

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 <address@hidden> wrote:
>> From: chen bin <address@hidden>
>> Date: Fri, 13 Oct 2017 12:39:54 +1100
>> Cc: address@hidden
>>
>> >> - 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.