[Openmcl-devel] Macro named » won't expand in Slime REPL

Helmut Eller heller at common-lisp.net
Thu May 21 19:26:34 UTC 2009

* Tobias C. Rittweiler [2009-05-21 12:45+0200] writes:

>> If Slime thinks that the stream used to talk to CCL is UTF-8 encoded
>> and CCL thinks that it's encoded in ISO-8859-1, ...
> The problem is not that the network stream is in the wrong encoding
> because the encoding, usually, comes from Emacs. That's also the reason
> that it'll work when you type in everything at the REPL.
> I think, the problem is that the file is encoded in utf8, but an
> :EXTERNAL-FORMAT of :DEFAULT in COMPILE-FILE is not utf8 in CCL as far
> as I can see. (In SBCL :DEFAULT is utf8 if unicode-enabled.)
> Perhaps Slime should send the buffer's coding-system with each request,
> and we should pass that over to COMPILE-FILE.
> Helmut, are you reading this list?

Yep, I'm reading.

Yes, in the regular setup Emacs tells CCL which encoding to use for the
network stream.  The default is ISO-8859-1 and Emacs should bark if the
user tries to transmit a character that is not encodable.  I guess that
Daniel Gackle changed the encoding to utf-8 by setting
slime-net-coding-system and that the network encoding is alright for

slime-compile-defun (C-c C-c) writes a string to a temporary file and
calls COMPILE-FILE on it.  We use the default encoding for the tempfile
but we can use utf8 just to be save.  We don't need to use the buffer's
coding-system because we know the "correct" content of the string and
are sure that WRITE-FILE and COMPILE-FILE use the same encoding.

slime-compile-file (C-c C-k) looks for Emacs-style -*- coding: ... -*-
variables in the file and uses that as argument to COMPILE-FILE.  If the
file has no such marker we fall back the :default external-format.
Well, at least that's the theory.  Until a few days ago the CCL SWANK
backend always used the default encoding but I suspect Daniel didn't use
-*- ... -*- markers anyway.  SLIME could use the buffer-coding-system in
this case, but I think it's stylisticly preferable to mention the
encoding in the file than to rely on Emacs.  If the encoding is written
in the file, ASDF and similar tools have a fair chance to pick it up
without the need of Emacs.

The best and simplest solution is to configure Emacs and CCL so that
both use the same default encoding.  I think we should encourage that
instead of making it easier to use strange configurations.  SLIME could
compare the default encodings and issue a warning if different.  That
could be done at startup or when compiling a file (or ASDF system).


More information about the Openmcl-devel mailing list