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: /lib/cpp not found in c-mode Date: Fri, 06 May 2005 10:43:41 +0300 Message-ID: <01c5520f$Blat.v2.4$77c7d860@zahav.net.il> References: <17013.26868.207510.370151@farnswood.snap.net.nz> <17013.52411.51878.781739@farnswood.snap.net.nz> <17014.39042.74353.677362@farnswood.snap.net.nz> <01c55014$Blat.v2.4$59df46a0@zahav.net.il> <01c550ec$Blat.v2.4$3b8fa220@zahav.net.il> <17017.64613.316775.721866@farnswood.snap.net.nz> <0FA9201A-8390-4924-BDE3-2857B0A33576@swipnet.se> <17018.38433.218342.918853@farnswood.snap.net.nz> <966E6F20-E10E-43E5-8E4F-A9C1043E6D47@swipnet.se> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1115376755 17311 80.91.229.2 (6 May 2005 10:52:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 6 May 2005 10:52:35 +0000 (UTC) Cc: nickrob@snap.net.nz, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 06 12:52:30 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DU0RK-0000KW-B8 for ged-emacs-devel@m.gmane.org; Fri, 06 May 2005 12:52:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DU0Qp-000288-1q for ged-emacs-devel@m.gmane.org; Fri, 06 May 2005 06:51:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DTxbC-0007Zu-Ok for emacs-devel@gnu.org; Fri, 06 May 2005 03:50:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DTxaM-00073n-Bp for emacs-devel@gnu.org; Fri, 06 May 2005 03:49:22 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DTxYj-00061P-IG for emacs-devel@gnu.org; Fri, 06 May 2005 03:47:42 -0400 Original-Received: from [192.114.186.66] (helo=romy.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DTxcp-0003UE-VN for emacs-devel@gnu.org; Fri, 06 May 2005 03:51:56 -0400 Original-Received: from zaretski (IGLD-83-130-245-224.inter.net.il [83.130.245.224]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id BDQ76270 (AUTH halo1); Fri, 6 May 2005 10:46:10 +0300 (IDT) Original-To: "Jan D." X-Mailer: emacs 22.0.50 (via feedmail 8 I) and Blat ver 2.4 In-reply-to: <966E6F20-E10E-43E5-8E4F-A9C1043E6D47@swipnet.se> (jan.h.d@swipnet.se) 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:36751 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36751 > From: "Jan D." > Date: Fri, 6 May 2005 06:51:38 +0200 > Cc: emacs-devel@gnu.org > > gcc -E can expand the macros just fine, it just needs the same input > (-I -D and -U) as gcc got when creating the executable. As others > pointed out, it is impractical to set this up if you are working on > several different projects at once. It is not impractical, since I actually do this in practice. One way to overcome the difficulties is to use the command history features offered by Emacs. Also, I really doubt that many people work ``on several different projects at once'', literally. I think it's an exaggeration, and that even if someone works on several projects, they don't switch from one project to another every minute, at least not in most cases, and neither do they need to use c-macro-expand all the time (see below). > Personally I don't see the need for expanding macros. One of the > reasons I use them in the first place is to hide details I don't need > to see. Expanding them while editing seems a strange thing to do. When you write your code, you don't need that. But when you need to understand some compiler message or obscure bug in code someone else wrote, it is sometimes hard to get along without this feature. A case in point is this message that GCC would once output while compiling regex.c: regex.c:5179: warning: comparison is always true due to limited range of data type The offending line was: if (RE_TRANSLATE (translate, *d) != *p++) Let me know how much time it takes you to figure out what is the problem without expanding the macros in this line with something like the feature we are discussing ;-) (It took me about 5 seconds after I expanded them.) Granted, this is not the most important feature for C programming, but I wouldn't say that ``I don't see the need for expanding macros''. So let's keep things in perspective here, okay?