Rich everything is possible with time and money.

> OK, here's a followup question. If there's no problem with <lf>,  
> then why do we need to remove them? Does that justify uglifying the  
> existing code base? It seems like way 3.9 handles newlines creates  
> a lot more problems than it solves.
>
> How often is removing <lf> an issue. Could displaying/hiding <lf>  
> be a feature that is toggled on and off? Couldn't <lf> be  
> automatically removed? This really doesn't seem like something  
> humans should be wasting their time doing. This is something that  
> should be automated.
>
> How did the <lf>'s get into the code base to begin with? Can't they  
> be blocked at the entry point?  (of course, that doesn't deal with  
> the existing problems--but it seems odd that Squeak would allow me  
> to paste in invalid characters--especially if those characters  
> cause problems).
>
> To me, displaying bad glyphs (at least with the source code in its  
> current shape) is a much worse problem than the issue of finding  
> rogue <lf>'s.
>
> Unless there's a strong reason to the contrary, the editors should  
> follow the old CS advice. Be generous in what you accept, be strict  
> in what you transmit (in this case, in what you save).
>
> You have yet to convince me that being able to see <lf>'s just so  
> we can delete them is a strong reason. For it to be a strong  
> reason, you need to show 1) that there is a concrete benefit to  
> removing the <lf>'s and 2) that always displaying the <lf>'s so  
> they can be deleted by hand is the best method for dealing with them.
>
>> But really, it's just a matter
>> of preference, so try using CrLfFileStream if you prefer that  
>> approach.
>
> Realistically speaking, I'll probably just go back to 3.8. However,  
> I would like to do my part to make Squeak better. Part of that  
> includes voicing my opinion when I think things are being changed  
> for the worse.

But this is not worse.
Because you have exactly the same problems in 3.8 but you do not see it.
So for our perspective this is really worse.

> 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). Yes, there are ways to work  
> around the issue, but that's not the point. Not all users will know  
> how to work around the issue. Having a reasonable default behavior  
> is vital.

But this was ALWAYS like that. We just display a glyph that was empty  
before.



>>> Here's my view. Back in the dark ages, moving text files from one
>>> system to another was a nightmare.
>>
>> I guess if we were out of the dark ages, we would not still be
>> using files.
>
> Sorry, I don't understand this comment at all.
>
> My point was that now, in the 21st century, our systems should be  
> smart enough to open text files properly, regardless of which  
> system they originated on. For any modern text editor, newline  
> incompatibilities are a think of the past. They should be a thing  
> of the past in Squeak.


Sure but we do not have the time to build new editor for now.
So if you want to see that happening introduce this behavior and send  
it to us.


> Remember, this is an issue that goes well beyond the Squeak source  
> code. There are many reasons why someone might want to open and  
> edit text files within squeak. This change will affect all of them,  
> and will make it much harder to use any text files that came from  
> other sources.
>
> Compatibility is still a good thing. But that's just my 2 cents.
>
> -Rich-
>
>
>