From: Francesco Potorti` <pot@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags`
Date: Wed, 03 Jan 2007 02:24:56 +0100 [thread overview]
Message-ID: <E1H1usC-0002GW-6l@tucano.isti.cnr.it> (raw)
In-Reply-To: <m3k6057ben.fsf@mid.gehheimdienst.de>
>Why shipping an own ctags/etags implementation at all? I mean Exuberant
>ctags works really well
The reason etags is there is fundamentally that it always was there, and
that it works well. Its maintenance has very low cost (I do it myself,
and I spend very little time on it), and having two more or less
equivalent implementation is not a bad thing, until they are
approximately the same quality. Finally, etags' copyright is FSF's,
like most GNU software.
That said, your question makes a lot of sense. Duplicating effort is
not a wise thing. For a start, I worked a lot with Xemacs people in the
past, and we succeded in using the exact same version of etags for both
the Emacs and the Xemacs distributions.
As far as four years ago, I had a brief mail exchange with Darren
Hiebert, the author of exuberant ctags. We both said we were interested
in studying the possibility of dropping etags in favour of exctags
(short for the real name), but no one of us had then the time to do a
deeper research on the relative strenghts and weaknesses.
What I discovered by then (note, four years ago) is that:
- etags was faster and generated a smaller tags file
- exctags has a much cleaner code, which is probably easier to maintain
- etags made a slightly better job at tagging complex C/C++ constructs
- etags knew about some structures for Emacs code (DEFUN, etc.)
- etags had a slightly wider choice of known languages
- exctags has an -R option for recursively tagging files in a dir tree
- exctags has a way of specifying some constructs on the command line
In fact, the only really significant differences I found was the code
cleanliness of exctags, and the -R option. The former is really
important only for the C/C++ parsing, which in etags is really
unreadable, but incredibly it works very well. The latter *the -R
option) is very nice, but I never had the time to implement it in etags.
Since then, maybe exctags has progressed. Etags has progressed little,
but something was done:
- etags recognises and parses #line directives
- etags supports regular expressions with regexp modifiers à la Perl
- etags now parses Html, Lua, Php and, to a lesser extent, Forth
>(at least in my experience as a C++ coder much better than the Emacs
>etags) and it's GPL software.
I am interested in this. Have you ever tried the version of ctags in
pretest? Even if in pretest, it is quite mature, and should perform
better than the etags shipped with Emacs 21. Would you send me a source
file where exctags performs better than etags?
next prev parent reply other threads:[~2007-01-03 1:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-24 20:01 [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags` Don Mullis
2006-12-25 5:41 ` Masatake YAMATO
2006-12-25 16:47 ` Don Mullis
2006-12-25 22:36 ` Francesco Potorti`
2006-12-26 14:13 ` Francesco Potorti`
2006-12-26 18:43 ` Don Mullis
2006-12-28 0:10 ` Francesco Potorti`
2006-12-28 5:48 ` Don Mullis
2006-12-28 10:21 ` Francesco Potorti`
2006-12-29 22:58 ` Richard Stallman
2006-12-30 20:36 ` Don Mullis
2006-12-31 1:46 ` Richard Stallman
2006-12-27 2:59 ` Richard Stallman
2006-12-30 12:15 ` Francesco Potorti`
2006-12-31 1:45 ` Richard Stallman
2007-01-02 11:41 ` Francesco Potorti`
2007-01-02 14:26 ` Frank Schmitt
2007-01-03 1:24 ` Francesco Potorti` [this message]
2007-01-03 12:06 ` Frank Schmitt
2007-01-03 14:33 ` Frank Schmitt
[not found] ` <m38xgk47lc.fsf@mid.gehheimdienst.de>
2007-02-05 8:25 ` Francesco Potorti`
2007-01-02 21:24 ` Richard Stallman
2007-01-03 0:40 ` Francesco Potorti`
2007-01-02 21:24 ` Eli Zaretskii
2007-01-03 0:42 ` Francesco Potorti`
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=E1H1usC-0002GW-6l@tucano.isti.cnr.it \
--to=pot@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.