On Wed, Sep 06, 2006 at 09:09:27PM -1000, Rich Warren wrote:
> 
> There are very few newline combinations. While you may not be able to  
> "know" in the absolute sense, you can make a reasonable assumption  
> that would work properly for 99.999% of the cases.
> 
> This is actually a solved problem. I have many text editors on my  
> system (BBedit and TextMate to name two) that can open text files  
> which use any of the common newline encodings. They display the text  
> in a reasonable manner, regardless of the encoding. At least in the  
> case of BBedit (though I believe others as well), they save the file  
> in the original encoding, unless you actually ask it to change the  
> line endings.
> 
> If other systems can handle this issue seamlessly, why can't we? 3.8  
> handled it seamlessly? Why can't we distinguish between non-text  
> ascii characters that cause problems for the systems (bugs) and  
> display them as glyphs, and alternate whitespace encoding which has  
> no effect on the system, which gets handled in the 3.8 manner?

Rich,

You may not be aware of CrLfFileStream, which has been part of Squeak
for many years. Setting CrLfFileStream as your default file stream
will do pretty much exactly what you are describing. If you want to
use it, change FileStream class>>concreteStream to answer CrLfFileStream.

Nowadays, Squeak uses MultiByteFileStream as its default, so changing back
to to CrLfFileStream might have some bad side effects (I don't know,
but I'm mentioning it as a caution). It certainly won't work for Squeak's
multilingual support, but this may not be important for you if you
mainly work in English.

Many people, myself included, prefer not to have Squeak do the automatic
line end conversion. But it's largely a matter of personal preference,
so give CrLfFileStream a try if you prefer that approach.

Dave