World: r4wp

See?

As far as I understood the plan, the internal "Latin 1" encoding 
is used to store Unicode codepoints 0-255. So this should be used 
already.

Kaj: why don't you open a ticket with a code example on github if 
something is broken or not working as advertised? I thought that 
was our process to get issues solved.

Andreas: that's what is supposed to be implemented, but now I have 
a doubt about it. Will need to check the code tomorrow.

Because you said it's not a priority and because I'm trying to ananlyse 
and fix things myself first. I'm just reporting my findings

Actually, I did one test that confirms Andreas' statement. The only 
way to get 8-bit data in is to compile a UTF-8 string literal that 
fits into Latin-1

Sounds like it works as advertised, then.

No, the console says you can input Latin-1, and you can't, not even 
through UTF-8

Neither can you compile Latin-1 nor read Latin-1 files nor other 
source data

I didn't see the latter claimed anywhere.

See above

Labelling the internal storage format "Latin 1" may be slightly misleading, 
though.

-=== Red Console alpha version ===-
(only Latin-1 input supported)

red>> s: "Español"
== "Espa"
red>> length? s
== 4

Console and compilation are two separate things.

I didn't see a claim anywhere, that you can compile Latin 1 sources.

Yes, and neither works, so there is no Latin-1 support at all, except 
in a corner case internally

The "internal corner case" is no Latin1 support either. It's purely 
Unicode support, with a more efficient internal storage.

If Kaj is top Red user, maybe the priorities could be adjusted then? 
Depends on Doc, though ...

Yes, and as you say, it's mislabeled Latin1, so there were several 
thing leading me to believe that Red already had Unicode and Latin-1 
support

I don't say that it is mislabeled, I say that it might be misleading.

Indeed, it it misleads me, I don't see why not everyone would fall 
over Red if we present it to the public

But if you all would prefer me not inform you of my findings, perhaps 
I should go back to working in silence?

Didn't say anything to that effect, and it's not what I'm thinking 
either.

So the claim that the console supports Latin1 seems to be incorrect.

Yes, that's why I reported relabeling my console versions

Let's give Doc a couple days to recover from pic-emitter, and I'm 
sure he'll clarify things.

Other than that incorrect claim, there's no Latin1 support in Red 
whatsoever.

Exactly

These issues are all important to know about, but it's easy to misread 
intent in text.

I think we're all on the same page, if not the same code page.

So for most purposes, Red is currently ASCII only

Well, Unicode is still working as advertised.

No, I've reported those issues the weeks before, and I'm working 
on fixing some of them, after Peter's work

http://red.esperconsultancy.nl/Red-common/dir?ci=tip

http://red.esperconsultancy.nl/Red-common/timeline

Which issues?

Discussed elaborately above

Which were disagreements at what is advertised as working.

Eh, then why did Peter implement a lot of code for it?

Because that's code which is still missing, as Doc stated multiple 
times.

Yes, and it was "advertised" as you say as already implemented. But 
why are we discussing this over? We are working on fixing it

I didn't see any advertisement beyond the basic Red string! supporting 
Unicode. Doc stated multiple times that the external en/decoders 
are not yet in place for this to be of much use.

It was announced last year that Unicode support was implemented in 
a week. What I found first is that Unicode support is useless, and 
now I've found that only ASCII is really supported

But I'm tired of trying to convince people of it. I'll just go back 
to finishing what I need

If Unicode support wouldn't be implemented, Peter would have a very 
hard time writing those transcoders.

If you're happy with your definition of "support", I'll go back to 
implementing the support I need

Just a matter of discerning internal implementation details and user-visible 
external features.

Could we say that internal unicode support exists, but is not available 
for I/O?

Kaj: you're basically saying that all the Unicode tests we wrote 
in the tests suite are lying...which is obviously wrong.

Precisely, yes.