Fwd: [ELPA] New package: mctags

[chen bin]

---------- Forwarded message ----------
From: chen bin <address@hidden>
Date: Sat, Oct 14, 2017 at 11:51 AM
Subject: Re: [ELPA] New package: mctags
To: Dmitry Gutov <address@hidden>


Sure. I also learned a lot by studying xref code.

mctags is targeted on a niche market (web front end developers) while
`xref` is a powerful one-for-all package. So they have totally
different road map.

For example, as a web developer, I prefer mctags to sacrifice
precision by fuzzy matching more candidates at the first stage. But
`xref` might prefer precision because it's also used by C/Perl
developers.

I've planed many more features for web front end developers in `mctags`.

As I know, there are a few auto-completion packages hosted on ELPA or
built in Emacs (complete-symbol, hippie-expand, company-mode, ivy's
completion at point). They all serve the users well in different
scenarios. For example, I use both hippie-expand and company-mode.
hippie-expand to auto-complete words in mini-buffer and company-mode
for anything.

Even there are some overlapping minor features between xref and
mctags, that's not a bad thing. A little bit rival is only good to
both packages, and more importantly, it gives the user choices. They
have freedom to choose the package fit in their specific need.

mctags respects the TAGS created by other programs. So it's impossible
mctags to conflicts with other programs. I understand someone has
concern about auto-updating which might override existing TAGS. But
auto-updating is disabled by default. I also have plan to make
auto-updating support any third party programs in the future by
allowing users to customize it.

Regards,
Chen

On Fri, Oct 13, 2017 at 11:33 PM, Dmitry Gutov <address@hidden> wrote:
> On 10/13/17 11:47 AM, Eli Zaretskii wrote:
>
>>>> 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.
>
>
> We could add filtering by file name and/or line contents to xref buffers
> too, though.



--
help me, help you.


-- 
help me, help you.