unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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?

  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

  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=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 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).