On Sep 5, 2006, at 3:22 AM, Klaus D. Witzel wrote:

> On Tue, 05 Sep 2006 11:42:04 +0200, Rich Warren wrote:
> ...
>> Here's my point.
>
> I do understand your point. But please don't take the following as  
> an offense.

No offense taken.

>
>> As a cross-platform editor, Squeak must be able to handle these  
>> transparently.
>
> Squeak is not the editor (Java is not the editor. Algol is (was :)  
> not the editor). Mind to talk about the tools you critisize. Not  
> every tool is newLine sensitive...

In java I agree. In Squeak, I have to disagree. When I browse classes  
in the browser, I can also edit them. The browser is an editor. When  
I open text files from a file list, I can edit them. The file list is  
an editor. Squeak is a combination programming language/IDE/ 
multimedia playground. That's one of the things I love about it. One  
of its many roles is "text editor."

>
>> Either it needs to automatically normalize everything to a single  
>> Squeak-standard newline, or it needs to accept both of these (and  
>> others, old Mac os used a third newline variant, and there may be  
>> some I'm not familiar with) in a reasonable and transparent way.
>>
>> I should be able to open any ascii text file (regardless of which  
>> OS it was written on) and it should appear as it was intended-- 
>> regardless of the particular newline encoding.
>
> Yes, almost everybody complains, see for example
>
> - http://www.google.com/search?q=newline+confusion
>
> I do not believe that there is a simple solution (because then all  
> these complaints would disappear immediately). I believe that a  
> COMPUTER cannot "know" what I want do do (or not to do) with  
> newLines. Perhaps I want to write newLine-compliant text on  
> platform A for use on platform B, who knows.

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?

>
>> Displaying the box glyphs is possibly good in some cases (for  
>> example, non-ascii codes that may inadvertently get copied from  
>> pdfs). A better solution would be to strip out any invalid  
>> characters automatically. After all, if they're invalid, they  
>> can't be doing anything constructive.
>
> The parser could do that when accepting source code, for sure. But  
> please do not do anything automagically when I just review source  
> code. I would like to see *all* *bugs* *in* *their* *original* *form*.


Are alternate line endings bugs? If they are bugs, then the code  
shouldn't run and someone should fix them. Balloon3d has tonnes of  
line-ending boxes, but I can run 3d code fine. If they're not bugs,  
then the system should accept them and display them in a reasonable  
manner.

Maybe there should be a tool that goes through the codebase and  
strips all unknown glyphs from the text. I don't know. But there are  
a large number of classes in my system that are littered with  
annoying boxes (all in the original image or donwloaded from SqueakMap).

-Rich-