[slime-devel] CMUCL unicode strings breaks slime

Helmut Eller heller at common-lisp.net
Sat Oct 2 07:45:30 UTC 2010


* Raymond Toy [2010-10-01 19:49] writes:

> Oh, that's a problem.  In the example, length is 3, but the string
> actually has 4 code units, so read-sequence only reads 3 code units,
> completely missing the last code unit.

I think we have the following options:

1) Don't support code points beyond 16 bits.  Clean and easy.

2) Introduce variants of length and read-sequence that use the same
   notion of character as Emacs.  Kinda messy and probably slow, but
   relatively easy.

3) Switch from character streams to binary streams so that we can use
   byte counts instead of character counts.  This has several
   advantages:
    - surrogate pairs are no problem
    - don't need flexi-streams for Lispworks
    - it would be easier to switch encoding after connecting
    - read/write-sequence is probably faster on byte streams
   disadvantageous:
    - more consing, and Emacs's GC isn't that good
    - need a string-to/from-bytearray function for every backend
    - breaks third party backends

Helmut





More information about the slime-devel mailing list