From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED!not-for-mail
From: Eli Zaretskii <eliz@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: etags failing with structure members
Date: Sat, 11 Mar 2017 18:37:37 +0200
Message-ID: <83varfdb1q.fsf@gnu.org>
References: <58C25BCF.4010704@gmx.at> <831su5fpx7.fsf@gnu.org>
	<58C3D124.1070501@gmx.at> <834lz0dpjp.fsf@gnu.org>
	<CAJnXXogxTyPLzBD7vm3LhWOSSpmFE+TAcU7XtyNodxVzTT_vmA@mail.gmail.com>
Reply-To: Eli Zaretskii <eliz@gnu.org>
NNTP-Posting-Host: blaine.gmane.org
X-Trace: blaine.gmane.org 1489250284 9180 195.159.176.226 (11 Mar 2017 16:38:04 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Sat, 11 Mar 2017 16:38:04 +0000 (UTC)
Cc: rudalics@gmx.at, emacs-devel@gnu.org
To: John Yates <john@yates-sheets.org>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 11 17:38:00 2017
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane.org
Original-Received: from lists.gnu.org ([208.118.235.17])
	by blaine.gmane.org with esmtp (Exim 4.84_2)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1cmk1o-0001zY-1F
	for ged-emacs-devel@m.gmane.org; Sat, 11 Mar 2017 17:38:00 +0100
Original-Received: from localhost ([::1]:43932 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1cmk1t-0002dt-MK
	for ged-emacs-devel@m.gmane.org; Sat, 11 Mar 2017 11:38:05 -0500
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47453)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <eliz@gnu.org>) id 1cmk1n-0002dl-My
	for emacs-devel@gnu.org; Sat, 11 Mar 2017 11:38:00 -0500
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <eliz@gnu.org>) id 1cmk1j-00030i-An
	for emacs-devel@gnu.org; Sat, 11 Mar 2017 11:37:59 -0500
Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47525)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@gnu.org>)
	id 1cmk1j-00030e-7i; Sat, 11 Mar 2017 11:37:55 -0500
Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1458
	helo=home-c4e4a596f7)
	by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.82) (envelope-from <eliz@gnu.org>)
	id 1cmk1i-0000hR-Ds; Sat, 11 Mar 2017 11:37:54 -0500
In-reply-to: <CAJnXXogxTyPLzBD7vm3LhWOSSpmFE+TAcU7XtyNodxVzTT_vmA@mail.gmail.com>
	(message from John Yates on Sat, 11 Mar 2017 10:42:23 -0500)
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.21
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel/>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.devel:212910
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/212910>

> From: John Yates <john@yates-sheets.org>
> Date: Sat, 11 Mar 2017 10:42:23 -0500
> Cc: martin rudalics <rudalics@gmx.at>, Emacs developers <emacs-devel@gnu.org>
> 
> On Sat, Mar 11, 2017 at 6:24 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > They look like a beginning of a K&R style function definition:
> 
> For many contemporary codebases support for K&R is only a liability.
> Might it be possible to drop such support (at least optionally)?

Even if we'd decided to drop that (and I'm not so sure we should),
someone would still need to rework the humongous state machine in
C_entries and consider_token (which supports all C-like languages,
including C++, ObjC, Java, etc.) to get rid of that cleanly.  If such
a volunteer steps forward, this question will become something we (and
the volunteer) should consider, yes.  But until that time, simple
localized changes are all we can afford, unfortunately, at least as
long as I'm the only one who dares to touch etags bugs.