From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Help etags parse lisp.h Date: Sun, 20 Mar 2016 20:11:36 +0200 Message-ID: <837fgx6muf.fsf@gnu.org> References: <83fuvl6p97.fsf@gnu.org> <87k2kxuk8i.fsf@linux-m68k.org> <83a8lt6nen.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1458497547 15816 80.91.229.3 (20 Mar 2016 18:12:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Mar 2016 18:12:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: schwab@linux-m68k.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 20 19:12:23 2016 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 1ahhpu-0001n2-9O for ged-emacs-devel@m.gmane.org; Sun, 20 Mar 2016 19:12:22 +0100 Original-Received: from localhost ([::1]:53935 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahhpt-0000sw-M2 for ged-emacs-devel@m.gmane.org; Sun, 20 Mar 2016 14:12:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahhph-0000sV-J8 for emacs-devel@gnu.org; Sun, 20 Mar 2016 14:12:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ahhpe-0001Mv-Ak for emacs-devel@gnu.org; Sun, 20 Mar 2016 14:12:09 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahhpe-0001Mm-8C; Sun, 20 Mar 2016 14:12:06 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1475 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ahhpd-00005y-H5; Sun, 20 Mar 2016 14:12:06 -0400 In-reply-to: <83a8lt6nen.fsf@gnu.org> (message from Eli Zaretskii on Sun, 20 Mar 2016 19:59:28 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:201952 Archived-At: > Date: Sun, 20 Mar 2016 19:59:28 +0200 > From: Eli Zaretskii > Cc: emacs-devel@gnu.org > > No, evidently because it wants to support K&R function definition: > > void foo () int arg; { bar = arg; } > > That's why, whenever it finds lines like the one above, it resets its > state only after the closing brace. > > Hmm... can a function definition use mixed K&R and ANSI style, i.e. > some arguments declared inside the parentheses and some outside, like > this: > > void foo (int arg1) int arg2; { bar = baz; } > > Or is this invalid C? If so, perhaps we could take note of nonempty > argument list. Actually, the K&R style is this: void foo (arg1, arg2) TYPE1 arg1; TYPE2 arg2; { body... } So the only way to discern between this and what we have in lisp.h is to find data type keywords inside the parentheses (hoping they are not hidden by some other macro).