Igor Stasenko wrote:
> 2009/11/17 Juan Vuletich <juan at jvuletich.org>:
>   
>> Igor Stasenko wrote:
>>     
>>> My 2 cents.
>>>
>>> Import: a text stream should detect a line-ending sequence
>>> automatically, or use explicitly specified line-ending sequence, if it
>>>  instructed so.
>>> Text editors should not bother with line end formats: their main
>>> purpose is to correctly display & edit the text, so its much more
>>> important to display it correctly, but quite unimportant in what
>>> format the edited text is stored.
>>> If current text editor uses cr as line ending - i'm fine with that.
>>> Lets then make sure, that it doesn't needs to deal with lf char, since
>>> any lf occurences should be wiped out (converted) before going into
>>> text editor - at text import stage.
>>>
>>> Export: at text export, one could always tell , what line endings he
>>> wants to see (by default it could use Smalltalk>>platformLineEndings
>>> ).
>>>
>>> I don't think that Squeak meant to be used as a generic-purpose text
>>> editor, thus, i don't see real importance in making a smart
>>> import-edit-export cycle which should care about preserving line
>>> ending sequence unchanged.
>>>       
>> There simply should not be any import-edit-export cycle at all. The purpose
>> of an editor is to show the user the characters that comprise the String
>> being edited, and allow him to add / remove characters at will. This is so
>> obvious that I feel silly saying it. Why would some characters be silently
>> messed by the system? I see no reason. It is like the horrible "ASCII mode"
>> in FTP, that breaks every file it downloads.
>>
>>     
>
> Look. Take a blank paper and write some text. Now tell me, where there
> any control characters lf's, cr's?
> Print some text using printer. Do you see any control characters
> there? Also, do you still think that any character which is sent to
> printer having a visual representation on a paper?
> Text is meant to be a presentation media, and how it is stored
> internally is completely irrelevant and up to implementation.
> User should not care about line endings nor about any other archaic
> crap which comes from 70-80's ancient terminals.
>   

You seem to be confusing a tool for displaying text with a tool for 
editing text. A text editor is for editing text. In Squeak, we are 
talking about editing Strings. For example, a system for "displaying" 
music is an audio player. A system for "displaying" HTML is a web 
browser. None of them allows editing the content, and none of them shows 
anything but the rendered media. But music software and HTML editors 
show all the "internal" structure, so the user (media creator) can have 
control.

> Once we're talking about converting a binary stream(file) into a text
> , it is a conversion from meaningless sequence of
> bytes into a representation media , which is text. And once we having
> this media, we're not talking about control characters anymore.
> User should not be able to input any terminal control characters,
> simply because there is no such in text editor as well as there are no
> terminal (hey we living in 21st centiry!).
>   

In Squeak, the editor is the way a developer has to interact (i.e. edit) 
String objects. It is not an end-user editor adapted to whatever 
end-user needs you have in mind.

> I hope it is cleared my point.
>
>   
>>>  There are a lot of text editors who can do
>>> this and much much more. And squeak text-editing is really suck
>>> comparing to existing word processors.
>>> Lets just face it: Squeak is not text-editing tool and never been.
>>> If one wants a full-featured text editor(s) in squeak - it can build
>>> one, with own import-edit-export cycle. But i don't see why basic
>>> system functionality, which meant to be used just for editing 1-2
>>> lines of source code, should care so much about that.
>>>
>>>       
>> Ok. So let's not fix it. BTW, are you sure you're the same Igor who once
>> said "IMO, in 21st century unicode support is A MUST for any development
>> environment. Of course, if you consider Cuis as dev environment, not as a
>> toy." ?
>>
>>     
>
> I don't see how it contradicts with the above. In contrast, i see much
> in common: We live in 21st century, free
> from black and white text terminals with control characters mess.
>   

In one paragraph you say that until it is perfect, it is just a toy. In 
the other you say that as it was always defective, we should accept it 
as it is. A clear contradiction to me.

>> Cheers,
>> Juan Vuletich

Cheers,
Juan Vuletich