[Openmcl-devel] ILISP & compiling
helink at sandia.gov
Thu Feb 21 11:56:58 EST 2002
> > I was also wondering if there were any way to get ilisp to
> > recognize the fact that the prompt that OpenMCL prints causes
> > the indentation to increase by two characters. When I type a
> > multiple line statement in the interaction buffer, the second
> > line is always indented two spaces behind what it should be.
> > > (dufun foo (x)
> > (+ 1 x))
> I don't know enough about how ILISP does things to know how hard this
> is to change. If no one else on this list knows, you might check the
> ILISP page at sourceforge.
I'll look into this more when I get a chance, but I warn you it's not at
the top of my list. The problem is that it *may* require digging into
.el functions provided by xemacs -- the functions in ilisp that take
care of indentation all seem to end up ultimately calling xemacs
functions for indenting sexps, and with args that don't look like
friendly numbers but rather like sexps. If that's actually necessary and
there's no other way to do it, and I hope I'm wrong about that, probably
the best thing would be to have ilisp redefine the xemacs functions to
be nearly identical but pay attention to whether you're in a sexp that
immediately follows a prompt, and add the extra two spaces.
If you're interested you could look in ilisp-ext.el and ilisp-ind.el at
functions like indent-line-ilisp (which calls lisp-indent-line, which I
think is an xemacs function).
Mostly I type forms into a lisp buffer instead of at the prompt, and
evaluate them from there. It means I don't care about the indentation in
the read/eval/print buffer, and it means that I don't have to do silly
things when I want to fix up a form and reevaluate it.
> > If I add an (in-package "COMMON-LISP-USER"), it works fine, but
> > then I have to call common-lisp-user::foo instead of just foo.
> > Maybe I don't understand how packages work? I thought that
> > common-lisp-user was supposed to be the default interaction
> > package.
> The COMMON-LISP-USER package is supposed to be the default initial
> package (and shouldn't contain anything that'd conflict with anything
> inherited from any packages it uses.)
I dunno, Gary, it sounds like openmcl has a user, so maybe at least
*package* should be fixed in the next release. IMHO it's easier for the
developers to change it back in their own versions when they need to
than for users (especially those new to lisp that aren't familiar with
packages yet) to figure out what to fix. Maybe *package* can't be fixed
by itself, I wouldn't know.
In the mean time, Brian, unless Gary thinks this won't work without
fixing other things as well, when you first start openmcl, execute the
following commands to fix the *package* default issue
(setf *package* (find-package :cl-user))
Then exit lisp and fire it up again to check that it worked -- just type
in *package* and make sure it's the common lisp user package. Finally
reload series or whatsit and see if that fixed the problem.
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel