From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: RFC: status icon support Date: Sun, 13 Jan 2008 18:47:22 -0800 Message-ID: <200801140247.m0E2lMeE010066@oogie-boogie.ics.uci.edu> References: <200801120157.m0C1v6WL020654@oogie-boogie.ics.uci.edu> <200801121352.m0CDqERq011212@oogie-boogie.ics.uci.edu> <85zlvb3yhn.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1200279007 25927 80.91.229.12 (14 Jan 2008 02:50:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Jan 2008 02:50:07 +0000 (UTC) Cc: tromey@redhat.com, schwab@suse.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 14 03:50:29 2008 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 1JEFPA-00073L-Pl for ged-emacs-devel@m.gmane.org; Mon, 14 Jan 2008 03:50:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JEFOm-0004TR-IX for ged-emacs-devel@m.gmane.org; Sun, 13 Jan 2008 21:50:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JEFOh-0004NI-2C for emacs-devel@gnu.org; Sun, 13 Jan 2008 21:49:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JEFOg-0004Kw-5j for emacs-devel@gnu.org; Sun, 13 Jan 2008 21:49:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JEFOf-0004Kb-Rh for emacs-devel@gnu.org; Sun, 13 Jan 2008 21:49:57 -0500 Original-Received: from oogie-boogie.ics.uci.edu ([128.195.1.41]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JEFOY-0001qt-LI; Sun, 13 Jan 2008 21:49:50 -0500 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by oogie-boogie.ics.uci.edu (8.13.6/8.13.6) with ESMTP id m0E2lMeE010066; Sun, 13 Jan 2008 18:47:22 -0800 (PST) In-Reply-To: (Richard Stallman's message of "Sun, 13 Jan 2008 21:01:03 -0500") Original-Lines: 35 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: by monty-python.gnu.org: Error: This connection is not (no longer?) in the cache. 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:86872 Archived-At: Richard Stallman writes: > The K&R function declaration style is obsolescent in C99. This means > that compilers are allowed to reject such code or accept it with a > warning message. In either case, they aren't allowed to ignore it. > > > Compilers are not allowed to accept this style of declaration without > warning. > > Not allowed? Nobody can stop us! > > The point is that Emacs does NOT have a convention against K&R > function definitions. When Dan told Tom Tromey to rewrite to ANSI > style, he implied that that was our convention. That is not so. Sorry, but that is not accurate characterization of my message. Here it is for the record: Please no K&R in new code. I am not sure if we actually have a policy about this. If we don't we should make it now required to have K&R in new code. It's already not possible to compile emacs with a K&R compiler, so please let's not add to this. The last thing we want is emacs to regarded as being a backwards project because it insists on using a language that was standardized in a different way 19 years ago. > I do not want to have a discussion about changing this, because there > are other, more important things to spend our time on. For instance, > a few bugs remain in Emacs 22. As you can see from the message cited above the discussion was not about changing what we have now, but about what to do with new code.