World: r4wp

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

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

A very similar thing happens when I paste Latin-1 into Windows

Here's what happens when I try to compile Latin-1 source code:

-= Red Compiler =- 
Compiling /home/kaj/Red/common/examples/Latin-1.red ...
*** Syntax Error: Invalid string! value
*** line: 5
*** at: {"Espa\ufffdol.txt" "Espa\ufffdol"^M
}

Compiling: 
	Red [ ] print s: "Español"
works fine here and prints the correct output when run.

Red input sources must be UTF-8 encoded.

You can't paste UTF-8 in the console, it supports only Latin-1.

Yes, so the Latin-1 promise is false

??

You can't paste Latin-1

Are you sure you're pasting Latin-1 and not UTF-8?

Yes, tried many times many ways

The printing backend doesn't fully support Unicode, either. This 
works on Linux:

print read "http://syllable.org"

But on Windows the output is truncated somewhere between the Spanish 
and Russian text parts

Does READ create a red-string!?

Yes

With the only function in Red that supports Unicode: string/load

string/load can only load UTF-8, so only ASCII and UTF-8 files can 
be read, not Latin-1

You caught me while in the middle of work on pic-emitter, I switched 
to master branch without saving my changes, and now my local git 
repo is messed up (not sure why it happened). I can't test anything 
anymore before finding a way to fix it...

Kaj, are you anyhow pressed for time with your solution? I can smell 
some push here, and Doc is now working on another priority. I would 
let him finish pic emitter and then ask for eventual rescheduling 
of priorities ...

I've just fixed my repo with the help of Andreas.

Kaj: I think you're right about the console, it handles correcty 
only ASCII input.

For: print read "http://syllable.org", do you feed string/load with 
an UTF-8 input even on Windows?

With the only function in Red that supports Unicode: string/load

 Red string! is fully supporting Unicode. Your issue is related to 
 I/O and Red has no support for that yet (except for the currently 
 hardwired stdout).

Doc, would you mind, if I would, from time to time, republish some 
of your tweets or other stuff on FB channel? I can still believe 
it has some value, maybe I am just used to the FB ...

Franckly, I've reached my limit wrt to communication channels. Also 
it would be counter-productive to me to do such tasks, I see no reason 
why it couldn't be done by someone else?

I think having comm lieutentants is a good idea.

Yes, that would be helpful.

OK, I'm on it :-)

Petr, I'm not pressed for time, except for my career in general. 
I only posted examples because Doc asked for them

I'm only pushing in so far as I have been inquiring about encoding 
support for several weeks, and the state of things has been downplayed, 
so I want it to be noted

Further, I'm working Unicode conversions directly into my I/O routines, 
so I need to know how Red currently functions and what the future 
plan is

ok, fair enough. I believe that Doc would wish Red development would 
go faster, but there's only 24 hourse per day, we know :-)

For example, there's an internal single byte encoding that's marked 
"Latin1", but I now know there is no way to get Latin-1 data in or 
out, so I wonder if this encoding will ever be used for more than 
7-bit ASCII

Yes, that's why I've been helping with the coding for over two years

yes, and as a contributor, you have been surely noticed :-) I am 
still somehow satisfied with how Red development goes, eg. even in 
comparison with R3. Nothing against R3, I wish Cyphre takes us to 
Android, but for general purpose needs, untill R3 gets protocols, 
multiline console, etc, stuff noticed on SO, it is no go for me. 
So, I keep my fingers crossed as far as Red development goes - it 
is nice to have a strong leader around ...

I'd better not comment on the Git issue, because it will be considered 
unconstructive :-)

Especially as it had nothing to do with Git, yes.

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