On SBCL/Win32 and SLIME and Cygwin emacs.
Alastair Bridgewater, March 2009.
[STATUS: DRAFT]


Over the past week, I spent some amount of time setting up SBCL/Win32,
SLIME, and Cygwin emacs on my "work" VM.  Initially, this seemed to be
a complete disaster.  With a little persistence, it turned out to be
an incomplete disaster.  Some subset of these steps may help if you
are using SBCL/Win32 and SLIME and non-Cygwin emacs.

This has been tested with SBCL/Win32 1.0.26.1, SLIME 2009-03-08 and
cygwin GNU Emacs 21.2.1.

I have SBCL installed under my Cygwin home directory, to parallel how
I set it up on Linux.  The first step is to tell SLIME about SBCL.

    (setq slime-lisp-implementations
          '((sbcl ("/home/Alastair/sbcl/bin/sbcl")
                  :init (lambda (pf cs)
                          (slime-init-command (slime-to-lisp-filename pf) cs))
                  :env ("SBCL_HOME=c:/cygwin/home/Alastair/sbcl/lib/sbcl"))))

Those of you who are not using cygwin can probably elide the :init
parameter, as it exists primarily to deal with the cygwin pathname
scheme.

Next, we tell SLIME about the cygwin pathname scheme.

    (setq slime-to-lisp-filename-function
          (lambda (filename)
            (replace-regexp-in-string "\n" ""
                                      (shell-command-to-string
                                       (concat "cygpath -m " filename)))))
    (setq slime-from-lisp-filename-function
          (lambda (filename)
            (replace-regexp-in-string "\n" ""
                                      (shell-command-to-string
                                       (concat "cygpath " filename)))))

As a deficiency in this interface, you can't easily switch out
filename translation functions on a per-lisp-implementation basis.
Additionally, cygpath unconditionally returns a trailing newline,
which has to be removed.  The final piece of the cygwin pathname mess
is to set the slime backend filename.

    (setq slime-backend (concat "/cygwin" slime-path slime-backend))

This is a hack.  There's no convenient place to force a filename
translation outside of the init function, and if the path doesn't
start with a slash then the init function thinks it's a relative path
and prepends slime-path to it, which breaks the naive approach of
passing it through cygpath as that returns a path starting with a
drive letter.

All this is sufficient to get things started, but there's a known
issue with the debugger.  When leaving sldb for any reason, SBCL stops
handling requests.  This turns out to be a known issue involving
read-char-no-hang not working on socket streams in SBCL/Win32.  One
workaround supposedly is to edit the slime source with a one-line
change.  The other is to make read-char-no-hang work "properly".  If
you're interested in the former, it's mentioned in the slime-devel
archives from around December 2008.  For the latter, there is an
incomplete hack called "new-serve-event" available.  Download
http://www.lisphacker.com/temp/new-serve-event.lisp and put it
somewhere convenient.  Next, create ~/.swank.lisp:

    (load "z:new-serve-event.lisp") ;; Or wherever you put it.
    (setf swank::*communication-style* :fd-handler)

Now the debugger works properly and we actually have fd-handlers.  So
long as you don't do anything heavily socket-based or involving pipes,
things should basically be okay.  There is one additional trick to
new-serve-event, and that is the ability to provide a function to
handle window messages, allowing a windows event loop to coexist with
a SLIME REPL.

The message handling hook is both simple and low-level.  Just setf
new-serve-event:*message-function* to a function which does a single
GetMessage() / DispatchMessage() or whatever more complex variant you
want and then returns.  So long as you don't get trapped in a modal
dialog box, SLIME can still get its requests serviced.

The observant may have noticed that the timestamp of
new-serve-event.lisp is from mid-october, 2007.  This probably says
something, but I'm not sure what.

EOF