From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: CEDET merge question Date: Sun, 13 Sep 2009 13:38:51 -0400 Message-ID: <1252863531.4770.230.camel@projectile.siege-engine.com> References: <87eiql2w5s.fsf@cyd.mit.edu> <87k50bixsl.fsf@engster.org> <1252759780.4770.76.camel@projectile.siege-engine.com> Reply-To: eric@siege-engine.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1252863476 3179 80.91.229.12 (13 Sep 2009 17:37:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Sep 2009 17:37:56 +0000 (UTC) Cc: cyd@stupidchicken.com, raeburn@raeburn.org, deng@randomsample.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 13 19:37:48 2009 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 1Mmt1F-0003cx-9B for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2009 19:37:45 +0200 Original-Received: from localhost ([127.0.0.1]:51307 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mmt1D-0007y7-S2 for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2009 13:37:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mmt19-0007xi-1D for emacs-devel@gnu.org; Sun, 13 Sep 2009 13:37:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mmt16-0007ww-90 for emacs-devel@gnu.org; Sun, 13 Sep 2009 13:37:37 -0400 Original-Received: from [199.232.76.173] (port=50189 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mmt16-0007wo-0x for emacs-devel@gnu.org; Sun, 13 Sep 2009 13:37:36 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10]:48033 helo=projectile.siege-engine.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mmt13-0006mW-Ix; Sun, 13 Sep 2009 13:37:33 -0400 Original-Received: from projectile.siege-engine.com (localhost [127.0.0.1]) by projectile.siege-engine.com (8.14.3/8.14.3/Debian-6) with ESMTP id n8DHcqaF011172; Sun, 13 Sep 2009 13:38:52 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.14.3/8.14.3/Submit) id n8DHcpw3011171; Sun, 13 Sep 2009 13:38:51 -0400 X-Authentication-Warning: projectile.siege-engine.com: zappo set sender to eric@siege-engine.com using -f In-Reply-To: X-Mailer: Evolution 2.26.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-Greylist: delayed 103573 seconds by postgrey-1.27 at monty-python; Sun, 13 Sep 2009 13:37:32 EDT 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:115282 Archived-At: On Sun, 2009-09-13 at 12:39 -0400, Richard Stallman wrote: > A very similar question to "why not make bison support Emacs Lisp > output", is "why not have gcc support tagging output". > > Could you please explain what you mean by that? Sure. Etags, ctags, gnu global, idutils and cscope all have parsers of some sort that parse C and C++ code. Some use regexp matchers. Others have primitive parsers. gcc, of course, has a full language compliant parser which it uses to compile code. I'm not a gcc expert, but I assume that as it parses, it keeps track of the various symbols (functions, variables, namespaces, etc) and where they are. (ie - debug info for gdb). As such, it should be possible for gcc to easily output text representing a tags file. Etags style would be fairly simple. The output of exuberant ctags is more complex. The data needed by CEDET is more complex still, but is still a subset of everything that gcc needs to know. For CEDET, if gcc saw this file: ------------- int main(int argc, char *argv[]) { } ------------- it would be handy (for my application) for it to output: -------------- (("main" function (:arguments (("argc" variable (:type "int") [ 11 20 ]) ("argv" variable (:pointer 1 :dereference 1 :type "char") [ 21 34] )) :type "int") [2 38])) --------------- though, to be honest, any text output that is very regular would be fine. The part that makes this imperfect is that in Emacs, a file that needs parsing may be in the middle of an edit. Handling these cases can be a bit tricky for my simplified parser, and gcc doesn't have that editing information available. To handle this, the CEDET tools have different ways to parse files, such as "on save", and can track when a file is unparsable and take alternate actions when that happens. Eric