Ok I’ve got an interesting comment from someone trying unravel: long strings are not shortened

I believe it’s a valid point and I’m certainly going to add #unrepl/string [prefix #unrepl/... {:get (business as usual)}] to the format. Anyone has a counterpoint?

I think that's an excelent idea

Can't see anything immediately wrong

what should be a reasonable length before elision? 80?

I'm going to jump in and suggest we're very precise about this also: do we work on glyphs, byte lengths, etc.?

80 sounds about right to me

why? why do we need to be precise? precision -> coupling -> brittleness

I'm guessing we can make it configurable at some point (though not necessarily initially)

@cgrand because there's been a number of bugs in things I've used around cutting off a character half-way through and then not renconvening that.

fun fact, the auto-complete I wrote for nrepl was originally broken because the bencode library I used was doing # of bytes rather than number of characters.

@pesterhazy it would be controlled by a dynvar like depth & breadth elisions

.substring should do the right thing though, @dominicm?

@dominicm would “I hereby promise to not cut a surrogate pair” be enough?

@pesterhazy substring don’t care about surrogates

@cgrand Probably. I think it's good to be ahead of this kind of thing is all, because string cutting seems fraught with peril historically.

yeah, I think "not cutting surrogate pairs" covers the cases I can think of.

Thanks @dominicm you made a very valid point! I kept saying people how I’ve been lucky to early attract a core of people interested in unrepl, challenging, questioning, criticizing the protocol.

Any plan of coming to Berlin on Nov. 8th?

Hmm, that's fairly close, and my girlfriend does want to see Berlin :thinking_face:

ah, but it'll be term time. So I doubt I could bring her. So I guess not. Unfortunate.