Improving D's support of code-pages

[Kirk McDonald]

Walter Bright wrote:
> Kirk McDonald wrote:
> 
>> Walter Bright wrote:
>>
>>> The problem is that whatever is sent to a file should be the same as 
>>> what is sent to the screen. Consider if stdout is piped to another 
>>> application - what should happen?
>>
>>
>> Let's say there's a function get_console_encoding() which returns the 
>> console's current encoding. I'm simply proposing that this:
>>
>> char[] str = something();
>> std.stdio.writefln(str);
>>
>> Should end up being equivalent to this:
>>
>> std.cstream.dout.writefln(encode(str, get_console_encoding()));
>>
>> So, to answer your question, if you use std.stdio.writefln, you will 
>> send a string encoded in the console's default encoding to the other 
>> application's stdin. This is the encoding the other application should 
>> be expecting, anyway (unless it isn't; code pages are annoying like 
>> that).
>>
>> In any event, if you explicitly want to output something in a 
>> particular encoding, this /will/ work:
>>
>> std.stdio.writefln(encode(str, whatever));
>>
>> This is because encode() returns a ubyte[], and writefln should print 
>> the data in ubyte[]s directly, as I suggested in my original post for 
>> this precise reason.
> 
> 
> stdio can detect whether it is being written to the console or not. 
> That's fine. The problem is:
> 
> foo
> 
> will generate one kind of output.
> 
> foo | more
> 
> will do something else. This will result in a nice cascade of bug 
> reports. There's also:
> 
> foo >output
> cat output | more
> 
> which will do something else, too.

Pardon? I haven't said anything about stdio behaving differently whether 
it's printing to the console or not. writefln() would /always/ attempt 
to encode in the console's encoding.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org