slime on github

[Helmut Eller]

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