+ Samium Gromoff _deepfire@feelingofgreen.ru:
| At Fri, 01 Dec 2006 09:11:27 +0100 (CET), | Harald Hanche-Olsen wrote: | > | > + Samium Gromoff _deepfire@feelingofgreen.ru: | > | > | Only if a let-bound variable could be made dynamic-extent, which, as | > | far as i know (i could be wrong,) elisp cannot do. | > | > Uh, as far as I know, that is the ONLY kind of let elisp knows about. | > | > (The cl package for emacs works pretty hard to make a lexically scoped | > version of let.) | | Hmm, perhaps i am doing something wrong, but, i tried to replace | the defvar + setq with a let, and now emacs says: | | error in process filter: Symbol's value as variable is void: *slime-in-dialect*
I now think that while what I said is technically correct, it was a bit beside the point. I only reacted to an isolated statement, without taking the larger context into account.
And this context is very likely related to non-synchronicity: You bind the variable *slime-in-dialect* and call slime. But after slime has finished its job and your function returns, the binding for *slime-in-dialect* is also gone, and so the process filter gets in trouble when it tries to access the variable later.
The easiest fix would be to return to using setq, but given that you are using this variable in slime-connected-hook, I think a better solution would be to ask the Lisp process itself what kind of lisp it is, essentially by running something like (slime-eval '(cl:lisp-implementation-type)) and using the response to decide which hook to run. (Note the importance of including the package name on ALL symbols when you call slime-eval. If whatever you send to the other side causes a reader error, the slime connection will be closed down.)
This should have the added advantage of doing the right thing when using slime-connect to connect to an already running lisp.
- Harald