[Openmcl-devel] very newbie question: emacs and OpenMCL

[Gary Byers]

On Sun, 11 Jan 2004, Gary King wrote:

> I'm trying to get EMACS set up to work with OpenMCL and I'm not having
> much luck. Part of the trouble is that my UNIX skills are mostly from
> 14-years ago and my EMACS skills are mostly non-existent! I have an OS
> X port of version 21.3.50 of EMACS running and OpenMCL 0.13 from a few
> weeks ago. I've tried both SLIME and ILISP and haven't had success with
> either. My guess is that I've put things in the wrong places through
> lack of knowledge of what the canonical places are. If someone could
> tell me where things are "supposed" to be installed in UNIX land on OS
> X (and perhaps where they have things installed), I'd really appreciate
> it!
>
> Thanks,
> --
> Gary Warren King, Lab Manager
> EKSL East, University of Massachusetts * 413 577 0176
>

Here's some intimidating Unix mumbo-jumbo that should either clarify
everything or confuse matters still further ...

Every Unix process has something called an "environment", which is
basically a mapping of string keys to string values.

You can use the function CCL::GETENV to look up the value of a
string in the environment:

? (ccl::getenv "PWD")	; the environment variable "PWD" usually
			; contains the current directory; this
                        ; may be shell-dependent.
"/Users/gb"		; I hope that you get different answers
? (ccl::getenv "USER")
"gb"
? (ccl::getenv "PATH")
"/sw/bin:/sw/sbin:/usr/X11R6/bin:/Users/gb/bin/powerpc-apple-macos:/Users/gb/bin:/usr/local/bin:/usr/local/teTeX/bin/powerpc-apple-darwin-current:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/ant/bin:/Users/Shared/DocBook/bin"

The last of these - "PATH" - is a colon-separated list of directories
that contain (or once contained, I'm not sure what some of those
things are doing there) executable programs that I use.  There are
several ways in which programs can launch (or "exec", used as a verb)
each other, and at some level (perhaps in the Unix kernel) the
absolute pathname of the executable file has to be determined.  The
most convient and probably most common convention used when one
program tries to "exec" another is to use look for the target program
(if the name isn't an absolute physical pathname) in the list of
directories in the PATH of the parent process.  If I type "ls" to the
shell (or use it as an argument to RUN-PROGRAM), that'll probably run
"/bin/ls", but might run something else in my case since a few other
directories (that might contain an "ls" program) precede "/bin" on my
PATH.

A process -usually- inherits its environment variables from the parent
process.  My shell startup files push several other directories onto
PATH, and I usually keep the "openmcl" shell script in
"/usr/local/bin", (which may or may not have been there originally),
so I can invoke it as "openmcl" at a shell prompt.  I usually use
XEmacs running under XDarwin, and (since XDarwin runs my shell startup
files) XEmacs inherits the same environment (and PATH) that I'd see in
the shell.  I can refer to OpenMCL as "openmcl" (without having to
qualify the pathname further) if I need to do so, and [X]Emacs uses
the value of PATH that it inherited to find the executable file (the
shell script).  [X]Emacs actually uses PATH to set up an elisp list
called "exec-path", so it's a little easier to manipulate inside
[X]Emacs if you need to.  In the setup that I'm most comfortable with,
it isn't necessary to do this.

The same's true if you just run Apple's tty Emacs from a terminal
window: Emacs will inherit the environment (including PATH) from the
shell and its "exec-path" variable should contain the same list of
directories that the shell would use.

If you use the GUI Aqua Emacs ... things are a little different.  The
parent process of anything lauched as an OSX is ... well, I'm not sure
what it is, exactly.  The last ancestor of the Emacs.app process that
bothered to set PATH to anything intesting was (IIRC) the process that
manages the Login window; I believe that the Finder, Dock, and
anything launched since is a descendent of that loginwindow process,
which is lurking in the background, waiting for another chance to let
you or someone else log in ...

If Emacs.app is in /Applications, launching it from a Terminal
(via "open /Applications/Emacs.app") will cause it to inherit
its environment from the shell's, and this would cause its
"exec-path" to contain all of the directories that the shell's
PATH does.

There's an Apple TechNote somewhere that explains how to set the
environment for the loginwindow process (and its descendents).  If
your PATH rarely changes, you might consider using this mechanism
to keep the "GUI" PATH in synch with the shell's PATH.

It may be somewhat simpler to just tell Emacs to include a few more
useful directories (including the one containing the "openmcl" shell
script) on its exec-path.  My .emacs contains

;;;---
(setq exec-path (cons "/usr/local/bin" exec-path)) ; in my case

(setq load-path (cons "/path/to/ilisp/" load-path))

(autoload 'openmcl "ilisp" "OpenMCL" t)
;;;---

and I believe that that's sufficient to get "M-X openmcl" to start.
(Customizing it to one's taste may require a bit of further work.)

As I was writing this long message, I noticed that someone suggested
setting inferior-lisp-program to a full pathname. That also works
around the issue of Emacs's exec-path being a little too minimal.
(IIRC, ILisp may use a different variable - something like
"openmcl-program" - to name the executable.)

Last (and perhaps least): in ILisp's case, you can persuade ILisp
to use any executable by invoking "openmcl"

C-U M-X openmcl

You'll be prompted for the name of a buffer to use and the name
of the program; specifying the /full/path/to/openmcl will work around
the exec-path issue.

The short version of this message: finding an executable program
depends in part on how the program that's doing the finding was
invoked.

Gary Byers
gb at clozure.com