Extras [was Re: [slime-devel] Re: recording and compiling changed definitions]

[Thomas F. Burdick]

> Maybe we should create a new module in the CVS repository, say
> slime-extras, for non-essential or not-mature features.  That would be
> very useful to make such code publicly available.  I'm not sure
> whether CVS is a good tool for such purposes.  Anyway, the core of
> Slime should be/become reasonably small and robust.
>
> I'd say the following qualifies as non-essential:
>  - fuzzy completion
>  - presentations
>  - class/xref browser
>  - complete-form
>  - stuff that tries to be to smart

This is a wonderful idea.  If the slime core were pared down
feature-wise to something more like slime from late-2004 (or less),
there'd be a nice stable, reliable base system.  As it is, I never
update anymore, because every time I do, something new is broken
thanks to another dwimmy extension.  If these were factored out into
modules, I could avoid the ones I dislike, load the unstable ones when
I feel like playing with them, and help improve/solidify the modules I
find especially important (xref, scratch-style interaction).

I think it would be a lower barrier to hacking if the extras lived in
a subdirectory or subdirectories of the main slime module in CVS, but
I don't feel especially strongly about it.

> It's not trivial to setup the infrastructure for this purpose.  Some
> obvious problems are:
>
> 1. how and when to load extra code

This is a bit problematic.  I'd do it by having slime-setup on the
emacs side take a list of extras to load; change swank-loader.lisp to
define a function that loads swank instead of actually loading it,
giving the emacs side (or the human) a chance to pass the list of
extras to match Emacs.

> 2. how to write backend specific code
> 3. how to write documentation

Why not just leave that up to each extra module, but with a preference
of just duplicating the infrastructure used by Swank?

> 4. what to do when the core changes in fundamental ways

All the extras break, until someone cares enough to fix them.  That's
how things work now, too, except the extras are all loaded into the
core.  But I doubt the core needs to fundamentally change very often,
especially if it's factored off on its own.

> Usually I'd say that it's not worth to bother and we should just drop
> the extras entirely, but it's quite tiring to tell every second guy
> that SLIME is more than feature complete and that I don't want to add
> new stuff.
>
> So, what do other people think of such an approach.

You mean burning out presentations with a hot iron like a cancer?  I'm
in favor of any way to get a core Slime, and if you personally have
the will to take one or the other approach, I'd be in favor.  The hot
iron approach is likely to lead to a fork, which I think would be less
detrimental to long-term reliability than the status quo, but more so
than having a core plus extras.