From: chen bin <chenbin.sh@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [ELPA] New package: mctags
Date: Fri, 13 Oct 2017 12:39:54 +1100 [thread overview]
Message-ID: <CAAE-R+8a_mnx_zYFQDFdkj30VLz5i4Fv85ZyJ+sL6zUvQW7UTw@mail.gmail.com> (raw)
In-Reply-To: <83mv4wl4yv.fsf@gnu.org>
On Fri, Oct 13, 2017 at 3:13 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: chen bin <chenbin.sh@gmail.com>
>> Date: Fri, 13 Oct 2017 00:24:17 +1100
>>
>> - 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.
For example, I can filter candidates in mctags with
"keyword1\|keyword2 !keyword3" (matching either "keyword1" or
"keyword2" but not keyword3)
>
>> - 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`).
Extra option could be added to tweak ctags cli in the future. 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.
> projects might use more sophisticated methods, for example see what
> src/Makefile does in Emacs to tag both the Lisp and the C names of the
> Emacs primitives.
>
Please note mctags RESPECTS the existing tags file created by other
programs. It's IMPOSSIBLE mctags will override existing TAGS created
by other programs (Makefile, for example) without user's confirmation.
>> - if no match found, fallback to `mctags-grep` to grep in current project. So you should always found matched
>> string
>
> But the matches found this way are not necessarily definitions, they
> can be references.
>
If definition is found, the grep will not be called. One reason I need
this is that the TAGS might not be updated for the latest code change
yet. Please note the UI make user clear that by displaying message "NO
tag found. Now you are seeing grep results" at the top of candidate
window.
>> - Improvement on performance (for example, ripgrep is automatically used as grep program if installed. GNU
>> grep is fallback grep program)
>
> Well, finding a tag via etags.el doesn't require Grep at all.
Grep is called if and only if mctags-find-tag fails. It's a useful
feature when TAGS is not updated yet.
For example, when I'm focusing on coding, I run `M-x find-tag` but no
matches found. I've to stop to ask myself: "What' wrong? Did I forget
to add definition? Or TAGS is not updated yet? Should I wait for ctags
to finish updating? Or should I manually restart ctags process?". I'm
forced out of "Flow" status by a simple "No matches found" message
because too many questions popup. But in mctags, we display "No tag
found" message PLUS the grep results. So I don't need THINK, I just
TAKE ACTION to filter grep results.
In my practice, this is huge productivity boost.
>
>> - tags file could be automatically updated when user save current file.
>
> Is this really a good idea? Updating TAGS means you need also revisit
> it, which could be a problem in some complex setups, when there's more
> than one tag table active at the same time. OTOH, etags.el is written
> in a way that makes frequent updates of TAGS unnecessary.
Some people might preferring TAGS auto-updating instead of manually
running ctags from time to time. Anyway, TAGS auto updating is not
enabled by default. So it will not conflict with your current
ctags/etags setup. You can safely use `mctags-find-tag` without any
worries on conflicts with other packages. At minimum, we give the
users an extra option to update TAGS. Users have freedom to choose
between these options.
mctags is especially newbie friendly. Open `mctags.el`, `eval-buffer`,
then `M-x mctags-find-tag-at-point`, that's enough. You don't need
even create TAGS file manually.
--
help me, help you.
next prev parent reply other threads:[~2017-10-13 1:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 11:05 [ELPA] New package: mctags Chen Bin
2017-10-12 12:11 ` Eli Zaretskii
2017-10-12 13:24 ` chen bin
2017-10-12 16:13 ` Eli Zaretskii
2017-10-13 1:39 ` chen bin [this message]
2017-10-13 8:47 ` Eli Zaretskii
2017-10-13 12:24 ` chen bin
2017-10-13 12:33 ` Dmitry Gutov
[not found] ` <CAAE-R+-Xxm3x5_u9jMO243SqfwaYfQs6XC=p1T0XQaAeFgy+dg@mail.gmail.com>
2017-10-14 0:52 ` Fwd: " chen bin
2017-10-13 13:42 ` Stefan Monnier
2017-10-21 19:59 ` Tom Tromey
2017-10-21 20:43 ` Stefan Monnier
2017-10-25 15:11 ` Tom Tromey
2017-11-12 3:19 ` Tom Tromey
-- strict thread matches above, loose matches on Subject: below --
2017-10-07 1:39 Chen Bin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAE-R+8a_mnx_zYFQDFdkj30VLz5i4Fv85ZyJ+sL6zUvQW7UTw@mail.gmail.com \
--to=chenbin.sh@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.