After being confused as to why (asdf:oos 'asdf:load-op :swank) wasn't working, I decided to look at the source to figure it out. The problem was that I was using ASDF-Binary-Locations to store my fasls elsewhere on the disk, and once swank-loader.fasl was put in the alternate location, it couldn't find any of the other swank .lisp files.
I created a new swank.asd that contains (I think) the full functionality of swank-loader.lisp. This allows the fasls to be relocated. I know, this means that changes have to happen in two places. I think there's a solution to this, too. Rather than have the .asd call swank-loader, reverse it. Write a new swank-loader that just loads the .asd (untested):
(defvar *source-directory* (make-pathname :name nil :type nil :defaults (or *load-pathname* *default-pathname- defaults*)) "The directory where to look for the source.") (handler-case (require :asdf) (condition () (load (make-pathname "asdf" :defaults *source-directory*)) (pushnew *source-directory* asdf:*central-registry* :test #'equal))) (asdf:oos 'asdf:load-op :swank)
This tries to use an ASDF outside of the swank directory first, but falls back to an included one if need be. Then it loads the system. This means that for the time being, slim.e-el (and anyone setting the slime-backend custom variable) doesn't have to change anything.
I know, it adds a dependency, but asdf is pretty ubiquitous anymore, and the inclusion of a fallback version in the source should catch a lot of the other cases.
Cons: - requires ASDF
Pros: - can eliminate a bunch of code used to manage file locations - gain flexibility of ASDF and its extensions (like ASDF-Binary- Locations)
It also seems like SWANK maybe should be made into its own ASDF- Installable package, with SLIME having only the emacs code and SWINE having the Climacs code.
Does anyone think any of this might be a good idea?