Re: Compile Mode and "host" Emacs

[Sebastian Wiesner]

2013/10/29 Stefan Monnier <address@hidden>:
> So, IIUC your setup is:
> - you have some kind of script that is run from Emacs.
> - you have no control over how Emacs runs it (presumably via M-x
>   compile, but could be M-! or anything else, and without any related
>   Elisp package).
> - this script needs to run Elisp code.
> - you care about machines where a useful `emacs' can't be found in $PATH.

Yes, that is about right.  More generally, I care for situations in
which the "emacs" in $PATH is different from the Emacs I currently
use, for whatever reason (e.g. testing Emacs Lisp code in an other
Emacs version, trying a trunk build, etc.)

> 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 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.

Is any harm done by changing these values to a more useful value?

> Emacs does not itself look for its own executable, usually;

Nonetheless we have "invocation-directory" and "invocation-name" in
Emacs Lisp, so the information is there.

And it is a useful piece of information.  I use it in Flycheck to
asynchronously check Emacs Lisp code, and I have seen Flymake recipes
doing the same.  It has also been used to implement asynchronous
functions for Emacs Lisp [1].

It is just not exposed to subprocesses from compile-mode…

> and of course, in the general case we can't find this file because it may not
> even have a name any more (you can `rm' the file after Emacs is
> started ;-).

Well, if Emacs goes away after being started, not being able to use
its executable is the least of all problems.  On my system, Emacs
won't even exit, if uninstalled after started, because libraries
backing some autoloadable `kill-emacs-hook` functions are gone.

Yes, strictly speaking, that's not exactly the same as just "rm
emacs", but who does this really?

[1]: https://github.com/jwiegley/emacs-async