From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: Re: /lib/cpp not found in c-mode Date: Tue, 3 May 2005 09:30:14 +1200 Message-ID: <17014.39910.373187.313040@farnswood.snap.net.nz> References: <01c54e8b$Blat.v2.4$b7e84380@zahav.net.il> <17013.33421.228027.508547@farnswood.snap.net.nz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1115087792 26298 80.91.229.2 (3 May 2005 02:36:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 3 May 2005 02:36:32 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 03 04:36:26 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DSnGk-0005dN-JV for ged-emacs-devel@m.gmane.org; Tue, 03 May 2005 04:36:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DSnNl-0004BE-MM for ged-emacs-devel@m.gmane.org; Mon, 02 May 2005 22:43:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DSj15-0001eH-I7 for emacs-devel@gnu.org; Mon, 02 May 2005 18:03:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DSj0s-0001WV-Gj for emacs-devel@gnu.org; Mon, 02 May 2005 18:03:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DSj0U-00012e-Cn for emacs-devel@gnu.org; Mon, 02 May 2005 18:03:14 -0400 Original-Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.34) id 1DSimS-0005rg-0O; Mon, 02 May 2005 17:48:44 -0400 Original-Received: from [202.37.101.8] (helo=viper.snap.net.nz) by mx20.gnu.org with esmtp (Exim 4.34) id 1DSigG-0004cM-75; Mon, 02 May 2005 17:42:20 -0400 Original-Received: from farnswood.snap.net.nz (p84-tnt1.snap.net.nz [202.124.110.84]) by viper.snap.net.nz (Postfix) with ESMTP id B64174B02AC; Tue, 3 May 2005 09:42:16 +1200 (NZST) Original-Received: by farnswood.snap.net.nz (Postfix, from userid 501) id A61AA62A9A; Mon, 2 May 2005 22:30:15 +0100 (BST) Original-To: Stefan Monnier In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.50.32 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:36608 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36608 Stefan Monnier writes: > >> Not only that, it IMHO shouldn't call "/lib/cpp" unconditionally, but > >> rather try several possible file commands, including "gcc -E", "cpp" > >> (without leading directories), etc. > > > Hopefully, it fails gracefully now. I use "gcc -E -dM -" now to generate a > > define list. Have you any ideas to make it more general? > > gcc might not be available either. > And the file may not be local (it may be accessed via Tramp or jka-compr). > I.e. "fails gracefully" can't be obtained without a condition-case. It uses call-process through a shell now and discards standard error so if gcc is not available no define list is generated. How would condition-case help? > And AFAICT the result is completely unused unless you happen to also use > gud-tooltips. Thats currently true. However, tooltips could be used to display the #define directives when just source browsing i.e. they don't need GUD. > You'd be better served postponing execution of such a command to the moment > when it's actually needed (i.e. when gud-tooltips are actually being used). I could do it at the same time that I check whether existing or new buffers require gud-minor-mode to be set. > If the user gets an error when she uses gud-tooltips, he won't mind, but if > she gets the error about something that she won't even ever use, she has > reasons to be upset. I see no reason now for an error to occur but, if we only use this feature with GUD, it clearly is more efficient to only activate for buffers that are part of the session. Nick