At Fri, 01 Dec 2006 20:22:47 +0100 (CET), Harald Hanche-Olsen wrote: [snip]
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.
I think i have a different solution -- pass the variable in question via slime-init-connection-state through into the asynchronously-called closure, and establish the dynamic binding inside it.
- Harald
regards, Samium Gromoff