From: Dmitry Gutov <dgutov@yandex.ru>
To: Tom Tromey <tom@tromey.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Generation of tags for the current project on the fly
Date: Sun, 21 Jan 2018 15:26:27 +0300 [thread overview]
Message-ID: <854cd0fd-5e4f-771a-0f58-b94373a2f98c@yandex.ru> (raw)
In-Reply-To: <87lggsnkwc.fsf@tromey.com>
On 1/21/18 2:57 AM, Tom Tromey wrote:
> Dmitry> 3. 'lib-src/etags src/category.c -u -o TAGS' results in having only
> Dmitry> that file's tags inside TAGS (before, it contained the entries for all
> Dmitry> .c files). This behavior contradicts the help and stops the rest of my
> Dmitry> testing in its tracks.
>
> Another bug on my part, I think I've fixed it now.
Thanks! It's working better now, but here's another experiment:
~/v/emacs-master (feature/etags-update|…) $ make tags
<completes okay>
~/v/emacs-master (feature/etags-update|…) $ echo src/doc.c |
lib-src/etags - -u -o src/TAGS
~/v/emacs-master (feature/etags-update|…) $ echo src/doc.c |
lib-src/etags - -u -o src/TAGS
lib-src/etags: invalid TAGS file
Also getting the same result after a third call to 'etags --find'.
> The next question for you is how you want it to work.
>
> Right now there are two modes:
>
> * The old mode (but with the possibility of -u)
That's how I'm going to use it for now. BTW, '--find' looks consistently
slower here than 'find -name "*.rb" |':
$ bash -c "time find . -name \"*.rb\" | ~/vc/emacs-master/lib-src/etags
- -o TAGS"
real 0m0,215s
user 0m0,200s
sys 0m0,116s
$ rm TAGS
$ bash -c "time ~/vc/emacs-master/lib-src/etags --find"
real 0m0,329s
user 0m0,180s
sys 0m0,136s
$ cat .etags
!*
*.rb
> * --find mode -- which implies -u. The .etags file is only read in find
> mode.
Not sure --find should always imply -u, actually (or '-o TAGS'). Might
be harder for debugging. Also, '--find' doesn't deal with deleted files,
so you'll delete one, call '--find', and the entry will remain in TAGS.
Anyway, my intention for now is to cherry-pick the '-u' feature as soon
as it's working well. Nothing against '--find', but it should probably
be a separate discussion.
> My idea for this code was to use locate-dominating-file to find the
> .etags file and just run "etags --find" from there on save.
That would complicate things somewhat, especially when .etags is not a
VC root of the project. You could create a .etags based project type,
though.
> However I know you'd like to use git ls-files, and maybe other things --
> you mentioned correctly handling file deletions.
Speaking of deletions, this is not strictly necessary (we could just
delete the whole TAGS and recreate), but it would be helpful if, when
passed a non-existing file that is in TAGS, 'etags -u' deleted it from
the index. Right now, it only complains "No such file or directory", but
keeps it in the index.
next prev parent reply other threads:[~2018-01-21 12:26 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 1:02 Generation of tags for the current project on the fly Dmitry Gutov
2018-01-12 9:01 ` Eli Zaretskii
2018-01-12 13:52 ` Dmitry Gutov
2018-01-12 18:52 ` Eli Zaretskii
2018-01-14 2:05 ` Dmitry Gutov
2018-01-14 16:21 ` Eli Zaretskii
2018-01-15 1:44 ` Dmitry Gutov
2018-01-15 5:37 ` Eli Zaretskii
2018-01-15 18:50 ` Dmitry Gutov
2018-01-16 17:50 ` Eli Zaretskii
2018-01-16 21:56 ` Dmitry Gutov
2018-01-17 15:40 ` Eli Zaretskii
2018-01-17 19:43 ` Dmitry Gutov
2018-01-17 20:12 ` Eli Zaretskii
2018-01-17 22:19 ` Dmitry Gutov
2018-01-17 22:28 ` Dmitry Gutov
2018-01-17 22:02 ` Tom Tromey
2018-01-17 22:44 ` Dmitry Gutov
2018-01-17 23:20 ` Tom Tromey
2018-01-18 0:14 ` Dmitry Gutov
2018-01-18 1:30 ` Dmitry Gutov
2018-01-19 1:21 ` Dmitry Gutov
2018-01-20 22:15 ` Tom Tromey
2018-01-20 23:57 ` Tom Tromey
2018-01-21 12:26 ` Dmitry Gutov [this message]
2018-01-30 4:45 ` Tom Tromey
2018-02-04 23:32 ` Dmitry Gutov
2018-01-30 5:05 ` Tom Tromey
2018-02-04 23:40 ` Dmitry Gutov
2018-02-05 17:06 ` Eli Zaretskii
2018-02-05 20:10 ` Dmitry Gutov
2018-02-06 19:36 ` Eli Zaretskii
2018-02-06 20:41 ` Dmitry Gutov
2018-02-07 3:26 ` Eli Zaretskii
2018-02-07 9:47 ` Dmitry Gutov
2018-02-07 21:30 ` Tom Tromey
2018-02-09 9:41 ` Dmitry Gutov
2018-02-08 20:31 ` John Yates
2018-02-09 0:22 ` Dmitry Gutov
2020-12-08 22:26 ` Dmitry Gutov
2018-01-17 11:08 ` Dmitry Gutov
2018-01-15 1:50 ` John Yates
2018-01-15 5:42 ` Eli Zaretskii
2018-01-15 15:01 ` Dmitry Gutov
2018-01-15 17:21 ` Eli Zaretskii
2018-01-15 17:45 ` Dmitry Gutov
2018-01-15 20:56 ` Matthias Meulien
2018-01-15 21:44 ` Dmitry Gutov
2018-01-15 16:33 ` John Yates
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=854cd0fd-5e4f-771a-0f58-b94373a2f98c@yandex.ru \
--to=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=tom@tromey.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).