Helmut Eller eller.helmut@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