Re: [ELPA] New package: mctags

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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 .<foo>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