From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Compile Mode and "host" Emacs Date: Tue, 29 Oct 2013 17:40:04 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1383082823 18499 80.91.229.3 (29 Oct 2013 21:40:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Oct 2013 21:40:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Sebastian Wiesner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 29 22:40:24 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VbH1T-0002Kh-Jr for ged-emacs-devel@m.gmane.org; Tue, 29 Oct 2013 22:40:23 +0100 Original-Received: from localhost ([::1]:49509 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbH1T-0001FG-5a for ged-emacs-devel@m.gmane.org; Tue, 29 Oct 2013 17:40:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbH1H-00010m-Fc for emacs-devel@gnu.org; Tue, 29 Oct 2013 17:40:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VbH14-0005K7-NF for emacs-devel@gnu.org; Tue, 29 Oct 2013 17:40:11 -0400 Original-Received: from relais.videotron.ca ([24.201.245.36]:18355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbH14-0005K0-Im for emacs-devel@gnu.org; Tue, 29 Oct 2013 17:39:58 -0400 Original-Received: from ceviche.home ([24.201.53.56]) by VL-VM-MR006.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MVG008399IL0RB0@VL-VM-MR006.ip.videotron.ca> for emacs-devel@gnu.org; Tue, 29 Oct 2013 17:39:57 -0400 (EDT) Original-Received: by ceviche.home (Postfix, from userid 20848) id 2A2A9660AD; Tue, 29 Oct 2013 17:40:04 -0400 (EDT) In-reply-to: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 24.201.245.36 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164659 Archived-At: >> So, yes, you're probably out of luck. If your script comes with some >> Elisp package, you could have that package add whatever you need to >> the environment, but without it, you're screwed. > I am screwed then. I presume there is no chance of having a new > variable introduced for this purpose, or changing the value of the > existing variables? > See, even if we leave my use case aside, the values of $EMACS and > $INSIDE_EMACS are generally not helpful. $EMACS is useless, indeed: for some reason we used to set it to "t" a long time ago, and a less-long time ago, someone complained that it broke Makefile-style use where $EMACS is supposed to hold the command to run Emacs. So now, we only add "EMACS=3Dt" if EMACS is not already defined. >From this point of view, it would be "natural" to set $EMACS not to "t" but to (expand-file-name invocation-name invocation-directory). But I'm afraid it would still break some of the use cases that are broken by "t", so we'd still have to do it conditionally (i.e. only when $EMACS is undefined). Furthermore, it would also break some people's .shrc where the test if $EMACS is "t" to detect if running in M-x shell (look for =ABif ("$EMACS" =3D=3D t) then=BB in http://www.opensource.apple.com/source/emacs/emacs-51/emacs/info/efaq-2 for an example). > Emacs tells subprocesses that they are running within Emacs by the > mere presence of $INSIDE_EMACS, but it just doesn't tell them, *which* > Emacs they are running inside. Even if this information serves no > useful purpose other than making some scripts more convenient, the > current value of $INSIDE_EMACS serves even less purpose. It is simply > "t", which conveys absolutely no useful information. I think this is a bug in compile.el: $INSIDE_EMACS should be of the form ",", as is the case when the process is run by comint, term, and tramp. Patch welcome. So, $INSIDE_EMACS should at least give you the version number, tho not the actual file name. > Is any harm done by changing these values to a more useful value? I think it would break some people's setups, yes. Maybe changing $EMACS as suggested above could be considered if we have a good replacement test for "$EMACS =3D=3D t" that has the advantage of being more reliable (e.g. something like "$TERM =3D emacs"). Still, I'm not sure it's worth the trouble to break people's .fooshrc. > My personal motivation for this feature is the Cask [1] project, which > pretty much covers the 3rd use case "install and update packages from > command line". We had a number of reports from OS X people who Why not make Cask an ELPA package? [ Even better: a GNU ELP package ;-) ] Then you could easily add a CASK_EMACS envvar from the autoloaded code of the package. Also, it seems just natural for Cask to itself be an ELPA package, doesn't it? Stefan