3. 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.
4. Integrate SLIME and ILISP. This would add multiprocessing support to ILISP and would allow SLIME to take advantage of
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. 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/