Re: Compile Mode and "host" Emacs

[chad]

On 29 Oct 2013, at 06:18, Sebastian Wiesner <address@hidden> wrote:
>> 
>> I don't think there's any portable way.
> 
> That's unfortunate.

It was (is?) an early design principle of unix systems that there isn't 
necessarily any such thing as `the path' or even `a path' to anything. This has 
a number of positive benefits surrounding hard links, soft links, movable 
files, and [un/re]mountable filesystems. Instead, we got conventions (not 
rules) about where things should be, and how to find them. It also has a cost, 
but it's relatively low - most of the time, when someone said "I want my 
program to know its place in the filesystem.", they really didn't need to know 
that, and there were better ways to accomplish their goals. For example, often 
these requests are an effort to work around the user's configuration choices, 
and that desire gets things wrong at least as often as it gets things right - 
even if it seems better in the short-term, narrow-focus view.

That said, there are times when the program really does want to know that data, 
so emacs provides a way to find it (invocation-*, mentioned above). Under 
macosx, for example, if you build a relocatable bundle, it really wants to be 
able to find its lisp libraries.

> I cannot but wonder what (stupid?) rationale let to the design of
> "$EMACS" and "$INSIDE_EMACS", if I have no chance to find out *what*
> Emacs I am actually inside of…

In most cases, programs don't care at all. When they do care, in most cases 
they care if they're running inside any sort of emacs at all or not. Your case 
appears to care inside which specific filesystem invocation of emacs it was 
run, which is unusual. Most cases, when examined, really are better off using 
rather than bypassing the user's configuration (PATH in this case). If I were 
using some code that wanted to know where emacs was installed, and I changed 
PATH for that code, I wouldn't want it poking around and guessing that it 
should ignore PATH. Conversely, if the user hasn't set PATH, but wants to 
interact with emacs, they generally will get similar sorts of wrong behavior if 
they're shell uses the wrong programs from bin and libexec (ctags, etags, 
emacsclient, etc).

In most cases, then, the right thing to do is to get/help the user configure 
emacs on their system correctly, rather than second-guess their intentions - 
it's harder to do, but gives the right result in more cases.

>> A better way would probably be to set some environment variable to the
>> full path in your init file, and then using that from the compile
>> process:
>> 
>> ;;;; .emacs
>> 
>> (setenv "EMACS_EXE_PATH"
>>        (file-truename (concat (file-name-as-directory
>>                                 invocation-directory)
>>                                 invocation-name)))
> 
> I am not in control of my users' configurations, nor can I reasonably
> demand them to change their "init.el" just to support a single script.
> Besides, if I tell them to change their "init.el", I might just as
> well tell them to select the target Emacs via the corresponding option
> of my script right away.

That's a good idea; you can also have your script run emacs (probably -batch) 
and have that emacs stash the info you need somewhere. I'll point out that if 
you expect your users to interact with emacs both from a gui launcher and from 
the command-line, it's almost never a bad idea to suggest and/or help them to 
configure their environment so that emacs works well in both situations.

Hopefully that helps explain why what seemed like a simple question wasn't 
quite as simple as you'd thought. If you can explain a bit more what it is 
you're actually trying to do, we can probably provide some helpful suggestions 
about how to accomplish your goals.

Thanks,
~Chad