Improving D's support of code-pages

[Walter Bright]

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.