On Sep 8, 2006, at 9:44 PM, Andreas Raab wrote:

> Yoshiki Ohshima wrote:
>>   Has anybody mentioned to Rich that one of the reason is that the
>> compiled methods hold integer indice into .changes and .sources  
>> files?
>
> This is not a valid reason (as are all the others in my opinion).  
> Transparent Cr/Lf handling does not prevent byte-oriented  
> positioning which is the only requirement for indexing sources and  
> changes file. I have advocated the use of CrLfFileStream since 1997  
> and nobody has ever brought a technical reason forward why this  
> wouldn't be feasible. I still feel just as strongly as back then  
> and it's plain incomprehensible (in particular for source code) not  
> to do CrLf conversion upon input. Why would we *knowingly* screw up  
> the source code with Lfs intermingled?
>
> Cheers,
>   - Andreas
>


This is exactly my feeling. Here's something else to mull over. It's  
a quote from the Java API:

"There are two properties which deal with newlines. The system  
property, line.separator, is defined to be platform-dependent, either  
"\n", "\r", or "\r\n". There is also a property defined in  
DefaultEditorKit, called EndOfLineStringProperty, which is defined  
automatically when a document is loaded, to be the first occurrence  
of any of the newline characters. When a document is loaded,  
EndOfLineStringProperty is set appropriately, and when the document  
is written back out, the EndOfLineStringProperty is used. But while  
the document is in memory, the "\n" character is used to define a  
newline, regardless of how the newline is defined when the document  
is on disk."

So, even Java handles this in a reasonable way. (Please note that  
this even applies to opening a "foreign" text file, editing it and  
saving. The file will have newlines saved in the original format-- 
everything is handled transparently). I hate to think Java is better  
than Squeak...

-Rich-