From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: fixing non-NS darwin Date: Mon, 04 Aug 2008 11:03:11 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <200808011544.m71Fi4UD026726@sallyv1.ics.uci.edu> <200808011605.m71G5Wmb010785@sallyv1.ics.uci.edu> <200808031559.m73Fx8wt013987@sallyv1.ics.uci.edu> <200808040120.m741K6YQ001518@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1217815406 24990 80.91.229.12 (4 Aug 2008 02:03:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Aug 2008 02:03:26 +0000 (UTC) Cc: Adrian Robert , Emanuele Giaquinta , Emacs Development To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 04 04:04:16 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 1KPpQl-0004oM-IO for ged-emacs-devel@m.gmane.org; Mon, 04 Aug 2008 04:04:15 +0200 Original-Received: from localhost ([127.0.0.1]:47195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KPpPq-000393-KB for ged-emacs-devel@m.gmane.org; Sun, 03 Aug 2008 22:03:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KPpPn-00038p-Ew for emacs-devel@gnu.org; Sun, 03 Aug 2008 22:03:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KPpPm-00038G-KM for emacs-devel@gnu.org; Sun, 03 Aug 2008 22:03:15 -0400 Original-Received: from [199.232.76.173] (port=51769 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KPpPm-00038B-Dx for emacs-devel@gnu.org; Sun, 03 Aug 2008 22:03:14 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:50455) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KPpPl-0005eR-NC for emacs-devel@gnu.org; Sun, 03 Aug 2008 22:03:14 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id E7A9E2C46; Mon, 4 Aug 2008 11:03:11 +0900 (JST) In-Reply-To: <200808040120.m741K6YQ001518@sallyv1.ics.uci.edu> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.2.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-kernel: by monty-python.gnu.org: NetBSD 3.0 (DF) 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:102021 Archived-At: >>>>> On Sun, 03 Aug 2008 18:20:05 -0700, Dan Nicolaescu said: >> > This is not defined anywhere in emacs, but there was this section in >> > an earlier version of darwin.h: >> >> > #if 0 /* Don't define DARWIN on Mac OS X because CoreFoundation.h uses >> > it to distinguish Mac OS X from bare Darwin. */ >> > #ifndef DARWIN >> > #define DARWIN 1 >> > #endif >> > #endif >> >> > Does anyone know where this IS defined? Also, I've been unable to >> > find a version of CoreFoundation.h that makes the check referred to. >> >> It's used in CoreFoundation.h in Mac OS X 10.1 - 10.3. >> >> BTW, why the above comment was removed? > Because it looked like dead code, and the description was not something > that made it clear that it was needed as documentation, nor was the > structure of the code. It's quite a common way in the Emacs code to comment out with #if 0 with leaving some explanation about why it is disabled. Especially for the case that people might make the same mistake again in future unconsciously if that part were completely removed. Cleanup tasks are usually tedious, and thus would be much appreciated if done carefully and appropriately. But as they are also inherently optional, not appreciated if done less carefully or unnecessarily aggressively as in the case of MULTI_KBOARD. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp