Re: Compile Mode and "host" Emacs

[chad <yandros@MIT.EDU>]

On 29 Oct 2013, at 06:18, Sebastian Wiesner <lunaryorn@gmail.com> 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