From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Francesco Potorti` Newsgroups: gmane.emacs.devel Subject: Re: [PATCH, RFC] etags/ctags v22.0.92 break Linux kernel `make TAGS/tags` Date: Wed, 03 Jan 2007 02:24:56 +0100 Message-ID: References: <1166990491.2706.205.camel@localhost.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: sea.gmane.org 1167787559 29377 80.91.229.12 (3 Jan 2007 01:25:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 3 Jan 2007 01:25:59 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 03 02:25:57 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1H1ut6-0003Ih-G3 for ged-emacs-devel@m.gmane.org; Wed, 03 Jan 2007 02:25:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H1ut5-0002rz-UV for ged-emacs-devel@m.gmane.org; Tue, 02 Jan 2007 20:25:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H1usq-0002r6-LO for emacs-devel@gnu.org; Tue, 02 Jan 2007 20:25:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H1usp-0002q6-O5 for emacs-devel@gnu.org; Tue, 02 Jan 2007 20:25:36 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H1usp-0002ps-I3 for emacs-devel@gnu.org; Tue, 02 Jan 2007 20:25:35 -0500 Original-Received: from [194.119.192.4] (helo=mx2.isti.cnr.it) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1H1uso-0001wk-G1 for emacs-devel@gnu.org; Tue, 02 Jan 2007 20:25:35 -0500 Original-Received: from conversionlocal.isti.cnr.it by mx.isti.cnr.it (PMDF V6.3-x3 #31251) id <01MBH5OM09E8A2B8FW@mx.isti.cnr.it> for emacs-devel@gnu.org; Wed, 03 Jan 2007 02:24:58 +0100 Original-Received: from tucano.isti.cnr.it (tucano.isti.cnr.it [146.48.81.102]) by mx.isti.cnr.it (PMDF V6.3-x3 #31251) with ESMTPS id <01MBH5OKUU5IA16WS6@mx.isti.cnr.it>; Wed, 03 Jan 2007 02:24:57 +0100 Original-Received: from pot by tucano.isti.cnr.it with local (Exim 4.63) (envelope-from ) id 1H1usC-0002GW-6l; Wed, 03 Jan 2007 02:24:56 +0100 In-reply-to: Original-To: Frank Schmitt X-INSM-ip-source: 146.48.81.102 Auth Optional-NoAuth X-fingerprint: 4B02 6187 5C03 D6B1 2E31 7666 09DF 2DC9 BE21 6115 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:64668 Archived-At: >Why shipping an own ctags/etags implementation at all? I mean Exuber= ant >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 mysel= f, 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 bo= th 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 interes= ted 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 mainta= in - etags made a slightly better job at tagging complex C/C++ construct= s - 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 tre= e - 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 eta= gs. Since then, maybe exctags has progressed. Etags has progressed littl= e, but something was done: - etags recognises and parses #line directives - etags supports regular expressions with regexp modifiers =E0 la Per= l - 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 sou= rce file where exctags performs better than etags?