World: r3wp

the /hour refinements where changed to reflect timezone   :-D   


goes to show we have a lot of voice in how R3 evolves... when we 
can provide concrete arguments.

Damned Windows. The heritage of old DOS is still present, resulting 
in one thing - we can't have good default console with R3. As http://curecode.org/rebol3/ticket.rsp?id=1305&cursor=7
was dismissed, we really need new console in R3 - no need to keep 
the default black crap Windows provides ...

If we don't get it, this one feature deeply degrades R3 experience 
for me - no tab completion, no multiline string, not freely resizable 
- current R3 console is of absolutly unacceptable quality for me. 
We need at least R2 level of console ...

there is nothing stopping Carl from adding the R2 console back into 
R3.  the current.exe is still a GUI app.

which is why he speaks about making another .exe which starts up 
in console mode.

I had many problems running sdk command-line apps when doing client 
work a few years ago... now at least this whole issue can be addressed, 
by simply flicking a switch in the host code and compiling a console 
version  :-)

I am really not satisfied with the Comments of Carl to #0001309 .
If I should read/as, I have to patch do and load and whatever.
I woud prefer a setting in the system/options.

I also think the "default" user text format should be configurable. 
  I have absolutely no desire to start using utf-8 for my code and 
data, especially when I have a lot of stuff that already is in iso 
latin-1 encoding.

if in ascii, it will be loaded ok, no?

ascii is 127 bytes... we are talking about the upper 127 chars.

sqlab - how do you want to do the conversion automatically? How should 
R3 know, what code-page the script is in? Maybe we could use header 
field, and load could act uccording to it?

Ascii is 255 ;-)

you trying to tell me, I can't load upper 127 bytes?

mmnt ...

upper 127 are NOT ascii.

they are different all around the world.

holy crap, wtf? :-)

It really does not work :-) I thought, that platform locale, as in 
R2, will be loadable, even without unicode.

http://en.wikipedia.org/wiki/ASCII

R3 should not try to do that automatically, if I do not want that

the 256 char encodings are often mixed up since they used to be loosly 
refered to  ANSI

http://en.wikipedia.org/wiki/Windows-1252

so what is an option? load/as? What if my script contains string 
in various charset?

The systems I know before, had a default codepage and did use Unicode 
only as an option.

I think it would have been enough, if R3 just added an Unicode datatype.
But now it's probably too late.

R3  is unicode from A-Z.   the code is unicode.

but for data, I would like to have default encoding of my choice.

It is really not good, that I can't load my own local codepage. How 
should I make my source-file UTF-8? My Notepad will not probably 
add any BOM header for me automatically ...

utf-8 needs no BOM... its only used as a signature.

if you only use ascii (lower 127 chars)  you will see no difference.

since rebol will load files as UTF-8 by default code doesn't need 
it.

guys, please, we are in 2009... how is it possible you're still using 
latin1...

hum... cause everything I use is ascii or latin-1 ?

well, windows ANSI..

Even you live in 2009, most people are born in the last century.
And many recipes, are older than the people, 
at least the good ones. (recipes for cooking food I mean:)

..and sticking to the old ways means living with the old problems 
... like not knowing how to interprete characters properly ... like 
AlrME for example ... it assumes makes the assumption that all text 
in messages is encoded as though it was entered on your own machine. 
So messages from Mac users are incorrecly displayed on Windows machines 
and vice-versa.


For me, moving to utf-8 is a much easier problem to live with than 
not being able to properly share text across different platforms. 
It may be different for you.

REBOL3's philosophy should be simple: UTF-8 is default. Anything 
else is possible, but must be optionally selected.

Livnig with the old problems means knowing the old solutions.

Displaying text in windows is a different problem to loading programs.

By the way, Ticket #0000589  leads still to a crash, even it was 
set to build again.

build = built

re-open it.

Loading programs are not totally immune from encoding problems. An 
unlikely but possible example:

if name = "Ashley TrŸter" [print "Hello Ashley"]

Then I would prefer, that name and the string to compare have an 
unicode datatype, 
as in
>> type? name
== UTF-8.

if name = U8{Ashley ...

but utf-8 editors aren't rare nowadays, and using utf-8 sequences 
isn't hard... really, if you tuely want to keep using as ascii editor

tuely = truely

But they do not convert automatically ..

handling encoding is complex in any environment... I had a lot of 
"fun" handling encodings in php, which uses such a unicode datatype... 
its not really easier... cause you can't know by the text if its 
unicode or ascii or binary values unless you tell it to load a sequence 
of bytes AS one or the other.

with mashup software its even worse... when done improperly, you 
end up with data with multiple encodings in the same document .... 
and then all hell breaks loose  :-)

at least converging to utf-8, all scripts by all authors will work 
the same on all systems.

cause there is just ONE encoding.