On Sep 7, 2006, at 11:18 AM, David T. Lewis wrote:


>>
>> This is what I'm struggling to understand. What possible benefit is
>> there in not converting line ends? Can you give me an example where
>> converting the line ends would cause a problem?
>
> I didn't say there was a problem. I said that this is my own
> personal preference. Which it is.
>
> As for an example, if I want to look at a file and see if it
> should have <lf> removed, it's harder to do if the tools disguise
> the line terminators.

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.

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.

>> 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.

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-