Zach Beane xach@xach.com writes:
For reference, slime-helper.el is part of quicklisp-slime-helper. It
I figure it would probably be something, but still wanted to rule out any external interference.
It looks like this:
https://github.com/quicklisp/quicklisp-slime-helper/blob/master/slime-helper...
Thanks, this is not the offical recipe, but is a de facto standard.
By the way in pull request
https://github.com/slime/slime/pull/83
there is a proposal for making ASDF the default swank-loading backend in SLIME, with slime-loader.lisp still being the fallback and fully supported (but doesn't need to load contribs upfront).
I consider it mostly finished and would appreciate it if any of the users/developers on this mailing list could spare a review. I'm not going to merge it without some feedback, since it's too big of a change.
I mention this in this thread, Zach, because it might make sense to use it to quicklisp's advantage, which already uses ASDF. Taking advantage of the new feature might simplify slime-helper.el.
If the goal of providing SLIME and its contribs as ELPA packages is additionally achieved, then maybe the need for slime-quicklisp-helper could be reevaluated.
What exactly is the use case that (ql:quickload :slime-quicklisp-helper) is good at solving? And how would it be easier/better/different than
M-x install-package RET slime-fancy RET
(if that were possible)?
João