- Flesh out SLIME with the functionality that is
available today in ILISP
and ELI. This is the "clean slate" option. It would
allow for a new Emacs
CL mode to be developed utilizing the best ideas
from ILISP & ELI. It also
requires the greatest amount of effort.
s/effort/fun/ :-)
Yes, that's a valid reason. However, if I do a wc of the elisp files in the different packages, I get the following results (lines/words/chars):
SLIME: 4345/14463/161611 ILISP: 15466/63798/565273 ELI: 19801/77244/743786
According to these figures, you've still got a lot of fun ahead of you to get feature parity with ILISP/ELI :-)
This is firmly the path we've taken, except that
we're primarily
stealing ideas from Emacs Lisp's development
environment.
And some of the stuff that I've seen come out of SLIME looks pretty neat. So far, I've only been able to drool over screen shots as I primarily use MS Windows.
- Integrate SLIME and ILISP. This would add
multiprocessing support to
ILISP and would allow SLIME to take advantage of
the rich functionality
already built into ILISP.
As Dan mentioned, we don't do any multiprocessing
yet, though we hope
our infrastructure will permit it with minimal
rewriting.
If you guys are interested in using TCP for your
connection, the
socket code is pretty easy. I don't think merging
with SLIME would be
a practical way to do it though.
I'm not advocating adding TCP socket code to ILISP or merging ILISP and SLIME. I just consider that another option. As I said, it could be a "win-win option" but it might also be a "Frankenstein". Since ILISP was built on top of comint mode, it would probably be too much effort to retrofit socket communication support as an alternative.
In any case, good luck with SLIME. I look forward to seeing what further developments you make in improving Emacs<->CL development environments.
Cheers, Bill
__________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/