- 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/
Bill Clementson bill_clementson@yahoo.com writes:
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 :-)
You might be surprised. If we copy that 15-year-old beta copy of comint.el that ILISP mysteriously includes into SLIME, we can grow by 25% right now ;-)
Time will tell all :-)
Cheers, Luke
--- Luke Gorrie luke@bluetail.com wrote:
Bill Clementson bill_clementson@yahoo.com writes:
According to these figures, you've still got a lot
of
fun ahead of you to get feature parity with
ILISP/ELI
:-)
You might be surprised. If we copy that 15-year-old beta copy of comint.el that ILISP mysteriously includes into SLIME, we can grow by 25% right now ;-)
Yeah, and if you copy in hyperspec.el and completer.el, you'll grow by another 25% too. Oops, never mind, I see you've already done that... ;-)
Cheers, Bill
__________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Bill Clementson bill_clementson@yahoo.com writes:
Yeah, and if you copy in hyperspec.el and completer.el, you'll grow by another 25% too. Oops, never mind, I see you've already done that... ;-)
Oooh, that hurts..
.. or at least, it would if I hadn't just removed the 1143-line completer.el and replaced it with half a page of new CL code.
Bugger. We'll never reach 15000 lines at this rate. ;-)
(hyperspec.el doesn't count - we're just bundling it for convenience, our only dependency is a key-binding.)
Thanks for keeping a guy on his toes :-) -Luke
Bill Clementson bill_clementson@yahoo.com writes:
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 a sense SLIME uses socket communication, yeah, it probably would be, but if you simply want to connect to a repl through a socket, comint supports that already. You might need an additional channel for sending signals.
-
Bill Clementson -
Hannu Koivisto -
Luke Gorrie