Bill Clementson's Blog

New Alternatives for Developing CL code with Emacs

Sunday, February 29, 2004

Until recently, if you were developing CL code with Emacs, you had the following three options:

1. Inferior Lisp Mode (ILM)
2. ILISP
3. ELI

• VLS (Vanilla Lisp Shell)
• SLIME (Superior Lisp Interaction Mode (Extended))

• Has very good documentation.
• Built on top of Inferior Lisp mode and thus shares the limitations of ILM that I outlined in my ILC2003 paper.
• Adds a number of new commands to ILM and makes it much more convenient to use.
• Has a facility to instrument Lisp code for debugging. This sounded interesting (and there is a lot of material in the documentation about this feature); however, I wasn't able to get it to work properly. In any case, it didn't seem like the instrumenting functionality was any more featureful then just doing the equivalent with Emacs keyboard macros.
• Some of the standard VLS key bindings use Emacs bindings that are reserved for the user to define (e.g. - "C-c l" is used for loading the current buffer's Lisp source). This is in conflict with standard Emacs key binding conventions and would irritate people who already have their own key bindings defined if they are "shadowed" by the VLS bindings.

• The documentation consists mainly of some CLiki pages ( SLIME description, How-to, Features, and Tips). Although basic, these are enough to get you started.
• Although SLIME uses ILM to kick off CL, all REPL interactions are done through SLIME's own REPL buffer, not the *inferior-lisp* buffer. This is a plus as it avoids the problems that ILM and ILISP users sometimes have with ILM and comint mode (e.g. - key binding conflicts, bad interactions with comint mode, etc).
• SLIME has the beginning of some support for multi-processing. I wasn't able to try this out as I used CLISP (which doesn't currently support MP); however, multi-processing support was a big advantage of ELI and was one of the reasons I listed for prefering ELI over ILISP in my ILC2003 paper.
• A lot of the useful functionality that is in both ELI and ILISP (but isn't in ILM) has been added to SLIME.
• SLIME has some additional functionality that is not present in any of the alternative Lisp modes:
  • A custom Emacs-integrated debugger. Looking at the screen shot of this on CLiki, I wasn't impressed; however, it really is quite a convenient feature when you use it.
  • Commands for visiting compiler notes.
• SLIME is still a bit buggy in places and will occasionally crash. In some cases, I had to manually kill the background Lisp process after such a crash. However, SLIME is still pre-release, so this is to be expected. However, on the whole, I would say that an experienced Emacs CL developer shouldn't be concerned using SLIME (even in its pre-release state). Just be sure to use the "fairly-stable" cvs branch (unless you're very adventurous!).

;;__________________________________________________________________________
;;;; VLS

(setq load-path (append (list (concat use-home "site/vls/elisp")
			      (concat use-home "site/vls/types")
			      (concat use-home "site/vls/types/elisp"))
                        load-path))

;; List of shells for vlsc command.
(setq vlsc-shells
      '((clisp "~/lisp/clisp.bat" "~/site/vls/types/clisp.el")))
(require 'vls)

;;__________________________________________________________________________
;;;; SLIME

(setq load-path (append (list (concat use-home "site/slime"))
                        load-path))
(require 'slime)
(add-hook 'lisp-mode-hook (lambda () (slime-mode t)))
(add-hook 'inferior-lisp-mode-hook (lambda () (inferior-slime-mode t)))
(setq inferior-lisp-program "c:/bin/clisp-2.32/full/lisp.exe
                                -B c:/bin/clisp-2.32/full/
                                -M c:/bin/clisp-2.32/full/lispinit.mem
                                -ansi -q")