From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Francesco =?utf-8?Q?Potort=C3=AC?= Newsgroups: gmane.emacs.devel Subject: maintaining etags Date: Mon, 11 May 2015 17:37:22 +0200 Message-ID: References: <5546DD4A.2080709@yandex.ru> <87r3qvnld1.fsf@gmail.com> <5548E08A.4090305@yandex.ru> <87mw1jndul.fsf@gmail.com> <554964CE.3040809@yandex.ru> <87oalxn756.fsf@gmail.com> <554AAD41.6060506@yandex.ru> <87vbg4lgn6.fsf@gmail.com> <554CB069.8090002@yandex.ru> <87sib7j9yf.fsf@gmail.com> <554CE8B2.7080408@yandex.ru> <87fv76kj0s.fsf@gmail.com> <83fv76p6ts.fsf@gnu.org> <831tiqox9e.fsf@gnu.org> <83twvmndr1.fsf@gnu.org> <554E0484.9010702@yandex.ru> <83mw1dophc.fsf@gnu.org> <554E8294.8070500@yandex.ru> <836180o5da.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1431358676 8305 80.91.229.3 (11 May 2015 15:37:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 May 2015 15:37:56 +0000 (UTC) Cc: Dmitry Gutov , eller.helmut@gmail.com, Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 11 17:37:46 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yrpm4-0007wj-W9 for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 17:37:45 +0200 Original-Received: from localhost ([::1]:38303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrpm4-0006Jj-7D for ged-emacs-devel@m.gmane.org; Mon, 11 May 2015 11:37:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrplx-0006EP-5U for emacs-devel@gnu.org; Mon, 11 May 2015 11:37:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yrplr-0006eq-L8 for emacs-devel@gnu.org; Mon, 11 May 2015 11:37:37 -0400 Original-Received: from blade3.isti.cnr.it ([194.119.192.19]:47921) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrpll-0006Zj-9s; Mon, 11 May 2015 11:37:25 -0400 Original-Received: from tucano.isti.cnr.it ([146.48.81.102]) by mx.isti.cnr.it (PMDF V6.5-x6 #32097) with ESMTPSA id <01PLUUE81NQOLLW2OE@mx.isti.cnr.it>; Mon, 11 May 2015 17:37:23 +0200 (MEST) Original-Received: from pot by tucano.isti.cnr.it with local (Exim 4.85) (envelope-from ) id 1Yrpli-0004JL-FF; Mon, 11 May 2015 17:37:22 +0200 In-reply-to: <836180o5da.fsf@gnu.org> X-INSM-ip-source: 146.48.81.102 Auth Done X-fingerprint: 4B02 6187 5C03 D6B1 2E31 7666 09DF 2DC9 BE21 6115 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 194.119.192.19 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186414 Archived-At: >> > C is a hard language to parse with ad-hoc parsers. If you know of a >> > better tool that doesn't get confused by the source at that point of >> > lisp.h (did you look at it?), name it. >> >> GNU Global doesn't, at least not in this example: >> >> ~/v/e/src> global -x Lisp_Object >> Lisp_Object 567 lisp.h typedef struct { EMACS_INT i; } Lisp_Object; >> Lisp_Object 577 lisp.h typedef EMACS_INT Lisp_Object; > >With the patch below, neither will etags. > >Francesco, do you see any problems with it? Eli, I see that you move around Etags's state machinery without problems. In the last many years, my main job has gradually moved away from programming, so every time I try to do something with Etags' sources I must invest some significant amount of time even to just download the latest sources and look at it. To be true, I am not even sure what sort of code revision backend Emacs developers currently use... Long story short, my role as Etags maintainer is, to be mild, obsolete, and maybe someone else (you? Stefan?) should take over :) Anyway, when I used to patch Etags, I always run a regression test, then updated the regression test with the case the patch was meant to address. The tests that I used can be found in the tree at , together with some garbage. The tests are invoked from the Makefile as the default target. If, as I hope, someone will care to install the regression tests in the Emacs tree I can assist with answers to questions. The patch you propose is the sort of patch that should be run against a regression test, as it is not always obvious what will happen in the general case. >--- lib-src/etags.c~0 2015-03-29 08:32:03 +0300 >+++ lib-src/etags.c 2015-05-10 12:15:23 +0300 >@@ -2862,7 +2862,10 @@ consider_token (char *str, int len, int > case st_none: > if (constantypedefs > && structdef == snone >- && structtype == st_C_enum && bracelev > structbracelev) >+ && structtype == st_C_enum && bracelev > structbracelev >+ /* Don't tag tokens in expressions that assign values to enum >+ constants. */ >+ && fvdef != vignore) > return true; /* enum constant */ > switch (fvdef) > { >@@ -3176,7 +3179,19 @@ C_entries (int c_ext, FILE *inf) > cpptoken = false; > } > if (cpptoken) >- definedef = dsharpseen; >+ { >+ definedef = dsharpseen; >+ /* This is needed for tagging enum values: when there are >+ preprocessor conditionals inside the enum, we need to >+ reset the value of fvdef so that the next enum value is >+ tagged even though the one before it did not end in a >+ comma. */ >+ if (fvdef == vignore && instruct && parlev == 0) >+ { >+ if (strneq (cp, "#if", 3) || strneq (cp, "#el", 3)) >+ fvdef = fvnone; >+ } >+ } > } /* if (definedef == dnone) */ > continue; > case '[': >@@ -3507,7 +3522,10 @@ C_entries (int c_ext, FILE *inf) > case fstartlist: > case finlist: > case fignore: >+ break; > case vignore: >+ if (instruct && parlev == 0) >+ fvdef = fvnone; > break; > case fdefunname: > fvdef = fignore; > >