Re: Compile Mode and "host" Emacs

[Sebastian Wiesner <lunaryorn@gmail.com>]

2013/10/29 Eli Zaretskii <eliz@gnu.org>:
>> Date: Tue, 29 Oct 2013 16:52:42 +0100
>> From: Sebastian Wiesner <lunaryorn@gmail.com>
>> Cc: Nathan Trapuzzano <nbtrap@nbtrap.com>, emacs-devel@gnu.org
>>
>> I would have preferred to have my question answered and my problem
>> solved rather than seeing my question arrogantly dismissed as "not
>> useful", and being lectured upon what my problem actually is.
>
> Perhaps if you explained in more details what is your problem, the
> issue would become more clear, and you could get more focused replies.
> As things stand, you only described in very general terms what you
> want to do, and on that level, Andreas is right: the OOB tool to
> communicate with Emacs is emacsclient.  Providing more details might
> clarify whether emacsclient fits the bill or not, and why, and if it
> doesn't, what might fit the bill.

"emacsclient" runs code in a running Emacs.  I don't want a use the
running session, but rather a fresh session, but using the same Emacs.

I think, there are a number of use cases for this:

An Emacs Lisp developer runs her ERT tests in a fresh Emacs session.
She has a Makefile with a "test" target, and a bunch of different
Emacs versions installed (e.g. Emacs 23.4, Emacs 24.2, Emacs 24.3,
three different Emacs trunk builds), to test her package against all
supported Emacs versions.   When developing her package, she has
different Emacs versions running in parallel to try how different
Emacs versions behave.   She wants "M-x compile RET make test" to use
the Emacs version she is currently in, and she does not want to
remember to explicitly specify the target version in each Emacs
session with "make EMACS=emacs23.4 test".

She also byte-compiles her libraries in a fresh Emacs session to make
sure that they cause no warnings (e.g. assignment to free variables,
unused lexical variables, undefined functions, whatever).  For this
purpose, she has a "compile" target in her Makefile, and she also
wants to compile against the very she is currently in.

A Emacs Lisp has written a little script to update all her installed
packages from the command line.  As she uses a lot of packages and
updates only once in a while, updates take long, and she wants to
continue working meanwhile.  Thus, she calls her update script via
"M-x compile", watches the compile buffer for progress, and calls
"package-initialize" once the update is done, to make her Emacs use
the new packages.  Obviously, she wants to install packages for the
Emacs she is currently using, and not the one, which is in "$PATH".
She has a few systems, where these are actually different:  A Fedora
system at work, where she has no root privileges.  She installed Emacs
trunk from source, and added it to the Gnome 3 menu.  Also an OS X
system at home, where she installed Emacs 24.3 as App Bundle, by just
dragging it into the "/Applications" folder.  In both cases, the
"emacs" in $PATH is different from the Emacs she uses and starts from
the GUI.  She does not want this Emacs to be used in her script,
because it would break in both cases, because the system "emacs" is
outdated.

I hope these use cases make my intend a little more clear.

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
installed Emacs as App bundle from http://emacsformacosx.com/, and
never added a "emacs" script to their path.  When these people used
"M-x compile" to invoke Cask, they got mysterious errors, because Cask
used "emacs" from $PATH, which is a out-dated Emacs 22 included with
OS X.  We could argue that their setup is broken, but as a matter of
fact, these people just used the standard installation procedure for
OS X applications, and are sometimes even surprised that there is
already an Emacs included in their OS X.

Just to make things clear: I agree that in neither of these cases it
is *essential* to expose the Emacs executable path to the subprocess,
but it would be definitely convenient…

[1]: https://github.com/cask/cask