Right now slime.el is 6250 lines, which makes it one of the larger programming modes line-count-wise. Besides making byte-compilation frustratingly slow, this size hides useful sub-components that (IMHO) could be made into their own, separate modules and used outside of Slime. For example, once the Slime-specific evaluation code has been factored out, there's a nice generic Elisp REPL hiding in there. With a bit of work today, I was able to turn it into a serviceable 500-line tool for interactive Perl development. While I did away with the asynchronous I/O features for simplicity's sake, I imagine these could be kept with a bit more work. The Xref browser (which I've never seen in action, not having CMUCL at hand) could be a similarly useful component.
The long-term upside of this is that many of the Slime interfaces, which are quite nice, could be used as a common face for other languages that support interactive development and introspection, like Perl, Python, and Ruby. The downside, of course, is that this would constrain Slime's development. However, since Slime is stable enough to have a manual now, this may not be such a problem.
Opinions?
/s
"Sean O'Rourke" seano@cs.ucsd.edu writes:
Right now slime.el is 6250 lines, which makes it one of the larger programming modes line-count-wise. Besides making byte-compilation frustratingly slow, this size hides useful sub-components that (IMHO) could be made into their own, separate modules and used outside of Slime.
Yes, I like the idea of factoring out any generally useful subsystems that are directly useful for other projects and can come out cleanly.
If you break e.g. the REPL and XRef buffer into separate files that are stand-alone and useful for other packages, without making them harder to use in SLIME, that would be cool.
But I don't want to split and generalize for its own sake. I find the big slime.el comfortable, and a fair portion of the code is still changing in major ways (esp. the evaluation mechanics / protocols).
For example, once the Slime-specific evaluation code has been factored out, there's a nice generic Elisp REPL hiding in there. With a bit of work today, I was able to turn it into a serviceable 500-line tool for interactive Perl development.
That's impressive :-). I wouldn't have guessed the REPL was so easily stand-alone'ified.
Cheers, Luke
-
Luke Gorrie -
Sean O'Rourke