Date: Sat, 17 Sep 2005 12:18:37 +0200 From: Helmut Eller heller@common-lisp.net
* 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.
Actually, there has been a bit of real code written for the McCLIM tools that uses Swank. I don't know many details about it, though.
I see the point about scheme48-mode, but I'm not sure I understand why having `package' as a buffer-local variable is unwise. Can you elaborate on that?
It's pretty common to write things like
(defun foo (package buffer) (with-current-buffer buffer (frob package)))
and this might not do what you think it does when package is a buffer-local variable. Symbols like `package', `module', `buffer', `string', `list' are problematic names for buffer-local variables. Let's reserve them for ordinary local variables.
That makes sense. Would it be OK if the lines were changed to something like -*- mode: scheme; scheme48-package: ... -*-? (The package local variable is very useful in Scheme48 development -- in the absence of IN-PACKAGE forms, which are nonsensical with Scheme48's module system, the information provided greatly speeds development.)
Still interested?
Maybe.
Would you please make up your mind, Sir? Yes or no?
I'm still interested. I'll maintain a separate Darcs repository just in case, though, it should ever become apparent that migration away from SLIME's source control be necessary.