Tango quibbles - please write tickets so we can track them

[kris]

Matti Niemenmaa wrote:
> kris wrote:
>> I'll open it again, and thank you ... you've written lots of tickets
> 
> No problem.
> 
> Any particular reason why you didn't see a reason to change it then, and do now?


Yeah, the issue is that we want to avoid scanning every string argument, 
  for every Layout instance, just to find one 'special' character. In 
other words, Tango formatting does not do a char-by-char output. 
Instead, it does a char[] slice by char[] slice, which is more efficient 
for a number of reasons. Note that the Win32 console handles it just 
fine as it is. At least, There's never been any indication that it 
doesn't work in the past. Perhaps you're redirecting console output to a 
file, and expecting to see \r\n in there instead of a \n?

One way to deal with this is to (selectively/optionally) inject an 
output-filter on the Console stream to do the scanning/translation. That 
would at least provide a choice for those who don't want/need this? We 
don't /really/ want to do this now any more than before (cos' it's a 
special case), but at least there's (finally!) an effective mechanism 
for making it optional. See, embedding the scan within the Console 
itself would slow it down considerably; we've got other people yelling 
at us to ensure the console screams along instead when redirecting (it's 
apparently twice as fast as the C console on input, and probably more so 
on output nowadays since we fixed the 'autoflush' issue). Stream filters 
are just cool anyway, and you /could/ use them to *dynamically* switch 
the behavior to produce Mac or *nix newlines instead. Worth considering?

Oh, and the .print/.newline thing you ran into is just a weird thing 
with D. It's a bit annoying, and I can see why you'd want '\n' for that 
keyboard

- Kris