Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Christophe Rhodes csr21@cam.ac.uk writes:
Does that clear things up? I think there are more problems than just this in the communications layer, but maybe this will do until after dinner... :-)
Well, I don't understand what the locale has to do with the SLIME coding system. Of course, the locale may have some have a multibyte coding system as default, but for SLIME we can use whatever we like. I think we should use a unibyte coding system. Simple, easy to understand, and efficient. You will not be able to send your emails with SLIME, but that's a restriction I can live with :-)
We do already
(set-buffer-multibyte nil)
In slime-net-connect we do:
(set-process-coding-system proc 'no-conversion 'no-conversion)
How does that sound?
Ah, I see... this is more complicated (much more complicated) than I thought. Sorry.
Consider what happens when I do (in my lisp) (code-char #x3bb)
because I want to get hold of a greek-lower-case-lambda character? I suppose slime will do prin1-to-string of the result of that as part of its repl implementation, and get the in-memory byte sequence (assuming an allegro/lispworks-like representation of strings for simplicity, but though the details are different in sbcl they're not very different)
00 23 00 5C 03 BB 00 00 # \ <l> ^@ = lowercase lambda
what should the lisp system do when it has to transmit this string through a socket to emacs? The stream between emacs and lisp is (on the lisp side) a character stream, so the lisp will look at this sequence as characters and apply an external format transformation: in a utf-8 locale, this will be to transmit the utf-8 corresponding to this sequence. If the emacs side doesn't read that as utf-8, problems of the sort that we're seeing now will occur.
And something of this form will happen whenever the lisp wants to emit a character which is unrepresentable in the non-multibyte buffer used by slime -- what does non-multibyte mean, anyway?
Meanwhile, it seems to me that there must still be some other encoding-dependent interaction around " *cl-connection*", as otherwise my "fix" to use base 128 in the communication would not have improved matters even slightly.
I feel we're still grappling with what the problem actually is, I'm afraid... sorry for not being clearer.
Cheers,
Christophe