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

[Helmut Eller]

* Brian Downing [2007-04-09 19:40+0200] writes:

> As I've watched fuzzy-completion grow in both features and size,
> I've wondered about something like SBCL's contrib system for Slime.
> For those who don't know about this, it contains modules that usually
> tie in somewhat tightly to SBCL's internals (so they benefit from being
> maintained in the same source tree), but don't require being built
> into each and every SBCL core.  An example contrib is SB-INTROSPECT,
> which provides the [mostly] stable interface Swank uses to poke at
> SBCL internals.  Something like this for Slime could be beneficial.
> I would nominate the fuzzy-completion feature as the first thing to use
> it, as it is quite a lot of code for a completion engine.

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

It's not trivial to setup the infrastructure for this purpose.  Some
obvious problems are: 

1. how and when to load extra code
2. how to write backend specific code 
3. how to write documentation
4. what to do when the core changes in fundamental ways

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.

Helmut.