slime on github

[João Távora]

Helmut Eller <eller.helmut at gmail.com> writes:

> On Sat, Jan 11 2014, João Távora wrote:
>
> I would call it "lib" and also wouldn't add it to the load-path.

OK. I'll move nregex.lisp, hyperspec.el and the new cl-lib.el and ert-el
into that directory and update the "Emacs 23 gotchas" section.

What about these ideas:

* With some work on swank-loader's *SYSDEP-FILES*, we could move
  metering.lisp, xref.lisp and the lisp backends.

* In that case we could organize lib into "backends" and "etc".

* While we're there, a "test" top level dir could host slime-tests.el,
  and the new files containing just contrib test as well (so loading
  them doesn't trigger the ERT warning).

> If you're breaking everybody's .emacs then you can just as well drop
> the non-autoload receipe.

I don't understand. AFAICT, the non-autoload recipe was not broken, and
I see no no reason to break it. In any case I'm _trying_ to do just the
opposite: not break user's ~/.emacs files.

As you reported the "visit lisp files early" case *was* indeed broken,
but I warned beforehand about possible instability. Anyway I have now
fixed it. I added new tests "readme-recipe" and
"readme-recipe-autoload-on-lisp-visit". If you can think of more cases
do tell me or add them.

But I agree with should make the autoload recipe the main recommended
recipe. Autoloads is how package.el and el-get are going to set things
up when we package SLIME for them and how MELPA sets things up when it
builds automatically.

Doing that:

* We can change `slime-setup' to not do the add-hook step.

* We can deprecate slime-enable-contrib and slime-disable-contrib. I had
  agreed before on mentioning them in the doc (they aren't now), but
  I've changed my mind. They promise functionality they can't really
  keep, don't you think? No emacs package I know promises to "disable"
  itself. There are "modes" though and SLIME uses plenty of them which
  *do* keep their promises.

* If we do the above step we might, someday in the future, make
  `slime-setup' essentially a no-op. `require' and autoloads are the
  normal Emacs way of activating functionality and I think there is (in
  recent GNU Emacsen) enough functionality to make
  `define-slime-contrib' obsolete.

So, in the future, (mapc #'require slime-contribs) might be all that is
required and it's much more idiomatic elisp. And the existing ~/.emacs
needn't be broken.

João