* 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.