Re: Line break normalization

 Hi All,
 
 I learned the following from an example I got from Bill.
 
 Although there exist several line break formats for a text file 
 depending on the environment, the file IO should absorbs the 
 variety so that the text data in memory always have "\n" as line 
 break. So, if this goes well, there should be almost no chance, 
 where one has to encode "\r\n" or "\r" delimited text in YAML. 
 This ideal situation is not always the case in reality, though.
 
 This completely makes sense. 
 I withdraw my proposal.
 
 Thanks, Bill.
 Sorry if my misunderstanding consumed your time, all.
 
 I will leave an option in my library for the line break conversion,
 just for some limited applications. ;)
 
 Best,
 Osamu TAKEUCHI


Bill Spitzak wrote:
> 
> 
> Osamu TAKEUCHI wrote:
>> Hi Bill,
>>
>> Thanks for your response.
>>
>>> First of all, there are plenty of Windows programs that expect a "\n" 
>>> character only. In fact when you try to write a "text" file in 
>>> Windows and write "\r\n" to them you will get "\r\r\n" with most of 
>>> the popular API's.
>>
>> Could you give me an example of APIs that converts "\x0d\x0a" into 
>> "\x0d\x0d\x0a"?
> 
>   FILE* f = fopen("foo", "w"); // no "b"
>   fwrite(f, "\r\n");
>   fclose(f);
> 
> The resulting file will have 3 bytes: "\r\r\n".
> 
> I really find it hard to believe you are unaware of this!
> 
>>  textBox1.Text = "abc\ndef\n";
>>
>> will not display the text in two lines.
> 
> So you are saying that a bare \n is treated differently than a bare 
> \r\n? That means it must be possible to distinguish these two sequences 
> in your data, which means one of them is going to require quotes and 
> backslashes.
> 
> Sorry but I am going to have to vote with having the newline 
> representation used by the vast majority of software, including Windows 
> software, be the one that is easier to read. Quote your string and put 
> "\r\n" in it if you need the two-byte sequence in the data.
> 
> Also this is just an obsolete and broken Windows MFC call. It is TRIVIAL 
> for you to insert the \r characters in front of the the \n before 
> sending your string to it (the opposite is not true because it is a 
> lossy mapping, both \r\n and \n turn into the same bytes). Propagating 
> Windows mistakes up into libraries because you are too lazy to work 
> around them is exactly why there is animosity toward Microsoft and Windows!
> 
>> I wish YAML's literal style text always be a multi line text in any 
>> environment.
> 
> For an awful lot of software, including C# and all that Microsoft stuff, 
> a \n IS a newline. Sorry you cannot win that argument.
> 
>>> In addition this will not round-trip. Current yaml will write a \n as 
>>> a \r\n to a file. There is no way to tell these apart.
>>
>> Sorry, I did not get your point.
> 
> In your proposal there is no way to distinguish a string containing just 
> a "\n" from a "\r\n" as both are turned into a single newline sequence 
> in the file!
> 
> Unless you are suggesting that everybody that wants just \n has to quote 
> the strings? Sorry but I'm afraid you are vastly outnumbered here.
> 
>> Currently, the spec allows to write a YAML document with any line 
>> break format, while the unescaped line breaks are always normalized 
>> into "\n" when they are parsed. We are sharing this point, aren't we?
> 
> Yes.
> 
> Now I would be willing to argue that yaml files should be "binary" and 
> as much of the bytes in strings be preserved as possible unchanged. Thus 
> you could distinguish \n from \r\n by the fact that they are two 
> different byte sequences in the file. This has the nice effect of making 
> text editors on Windows useless, so you can perhaps learn some of the 
> pain that you are causing! However I doubt this proposal would get very 
> far with the yaml designers.



------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf