[slime-devel] Re: sbcl regression with slime

[Christophe Rhodes]

Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:

> Christophe Rhodes <csr21 at 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