Helmut Eller writes:
- Taylor Campbell [2005-09-17 04:47+0200] writes:
Is there more interest in maintaining a well-engineered & -specified protocol for general Lisp interaction, or in producing just an environment for Lisp development in Emacs, regardless of how messy the internals are, and without any provision for reuse & extension in other directions? For instance, the notion of utilizing Swank in the McCLIM tools has been considered, where those tools would serve as a Swank front end, if the protocol were sufficiently general and well- abstracted. (I'm not saying that SLIME should provide this, but rather that it may be a worthwhile direction to consider.)
I for one, am not interested in "general Lisp interaction". Emacs is the only front-end I want to use anyway. I'm however interested in interaction of Emacs with external (possibly non-lisp) interpreters/debuggers. Most of the talk about using SLIME for other things I have heard has not been more than that: talk. And I think it would be a bit silly to provide for reuse and extension if there's no actual application which uses it.
I have both an Ltk debugger and an Ltk Smalltalk-style-browser that use swank. They use swank not just for portability, but also to be add-on tools to slime (eg, it's no fun when you're looking at an Ltk window, and a debugger pops up in an emacs somewhere -- and at the same time, I want to be able to use SLIME for 95% of my Lisp interaction). Before releasing them, I'll have to clear them past my own personal QA (they shouldn't be patches against 4-month old releases), and clear them by my employer ... but, I can certainly vouch for other tools existing atop swank.
I like the slime/swank assumption that everything is ANSI and AMOP compliant as far as makes sense. And it definately makes my life easier as a swank-frontend implementor.