Re: Compile Mode and "host" Emacs

[Stefan Monnier]

>> 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=t" 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
.<foo>shrc where the test if $EMACS is "t" to detect if running in
M-x shell (look for «if ("$EMACS" == t) then» 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
"<version>,<context>", 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 == t" that has the advantage of being more reliable
(e.g. something like "$TERM = 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