So after all of this energetic opinionating, have you bothered to
take the time to enable CrLfFileStream in your own image?
It will
take you about 20 keystrokes, which could doubtless be improved, but
is still considerably less that it took me to to compose this note.

On Sat, Sep 09, 2006 at 03:55:58PM -1000, Rich Warren wrote:
> 
> On Sep 8, 2006, at 12:35 AM, Bert Freudenberg wrote:
> 
> >Rich Warren schrieb:
> >
> >>How often is removing <lf> an issue.
> >
> >Often enough to not be done automatically. It took editors a lot of  
> >time to become binary-safe, most still are not. You also need UI to  
> >show which line end convention is active, and you need to provide  
> >conversion methods.
> 
> Maybe I asked the wrong question. Can you give me an example where  
> automatically replacing an invalid EOL character with a proper one  
> (eg replace <cr><lf> with <cr> or replacing  a solitary <lf> with  
> <cr>) results in a bug?
> 
> Can you show me an instance where having the <lf> causes a bug in the  
> code?
> 
> The "uglified" code seems to work just fine, whether or not it has  
> the <lf>'s.
> 
> >
> >>How did the <lf>'s get into the code base to begin with?
> >
> >They were invisible.
> 
> No, this is "why are they still in the code base?" I asked a  
> different question. How did they get in there in the first place? I  
> doubt people entered <lf> at the keyboard. Did they get pasted into  
> Squeak? Were they loaded from files? It seems like line normalization  
> should be done at the port of entry.
> 
> >
> >>You have yet to convince me
> >
> >I don't have to convince you of anything. You have to convince us  
> >to change the status quo. A good implementation is very convincing ;-)
> 
> If you want me to agree with you, then you need to convince me.  
> Sorry, I just assumed the first part of that sentence went without  
> saying. If you don't care what I think, then no. You don't have to do  
> anything.
> 
> >
> >>To me, this seems like a poor design decision. I think there will  
> >>be a lot of unforeseen consequences (for example, making Squeak  
> >>incompatible with windows text files).
> >
> >It's as compatible as it ever was. The behavior is exactly the same  
> >as in 3.8, but you now *see* that something is wrong.
> >
> >If in 3.8 you edit a windows CRLF file it appears fine. You press  
> >return, which inserts a CR. You save the file, and *boom*, a wrong  
> >line end in your file that other software may trip about. Like  
> >notepad. And you saw *nothing* in the Squeak editor.
> 
> Yes, this is a bug, but it's a different bug. Arguably it's a lesser  
> bug. The number of cases where it becomes an issue (open CRLF file in  
> Squeak, modify file in Squeak, Save file, and then open in an  
> external editor) is a subset of the cases where 3.9 causes problems  
> (open CRLF file in Squeak).
> 
> So, 3.8 is more compatible, because at least it lets me open and read  
> CRLF files transparently.
> 
> -Rich-