On Sun, Jan 12 2014, João Távora wrote:
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).
I'm not very enthusiastic about that. The technical reason to do it isn't so obvious. There may aesthetic reasons, but those are, as always, debatable.
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.
Well, you said that changes to the non-autoload recipe may be necessary. If you do that then you could also drop it entirely.
[...]
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.
Not sure what slime-enable-contrib promises. It practice, it adds various hooks and slime-disable-contrib removes those hooks again; that's certainly possible. It would also be possible to enable resp. disable modes with these commands, tho, perhaps not very useful. Binding/unbinding keys may be possible but it's obviously tricky.
I don't think these commands need to be documented in the manual, but they are useful for debugging.
- 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.
Doesn't sound very idiomatic to me. IMO, loading a package and enabling it should be separate steps. The elisp manual seems to agree with me (elisp)Coding Conventions::
* Simply loading a package should not change Emacs's editing behavior. Include a command or commands to enable and disable the feature, or to invoke it.
Helmut