[Openmcl-devel] Macro named » won't expand in Slime REPL
Helmut Eller
heller at common-lisp.net
Thu May 21 12:26:34 PDT 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
him.
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).
Helmut.
More information about the Openmcl-devel
mailing list