Hi Igor,

Igor Stasenko wrote:
> 2009/11/17 Juan Vuletich <juan at jvuletich.org>:
>   
>> Hi Stephan,
>>
>> stephan at stack.nl wrote:
>>     
>>> Juan wrote:
>>>       
>>>> Showing all in the same way is misleading. Different Strings should look
>>>> different in the editor!
>>>>         
>>> Why should they? No system (old mac, unix, dos) has the correct
>>> ASCII behaviour and no user expects them to. Squeak is multi-platform
>>> and has its own internal conventions.
>>>       
>> 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.
>>
>>     
>>> Conversion should always default
>>> towards the internal conventions, with the possibility to override that
>>> behaviour. Default write-out should be to platform standard, eliminating
>>> multi-convention line ends. If the user wants something different, she
>>> knows enough to override the defaults.
>>>       
>> Squeak is not an application. Squeak is an object environment. Squeak
>> editors don't edit files. They edit Strings. The behavior of the editors and
>> that of the code used to read the strings from files or to store them back
>> to files are completely unrelated issues. There could be no files at all. Or
>> the files could be in a web server or whatever. They could be dynamically
>> created by some other application. They could be part of an object you're
>> inspecting. Assuming there is a well known "platform standard" to follow is
>> wrong. May be in an application... Then the programmer doing that
>> application might do whatever conversion fit his needs. But the base system
>> should do none by default.
>>
>>     
> and it doesn't.
>
> You seem mixing the roles of:
>   - text reader/writer/converter
>   - text editor
>
> Role 1:
>  - different system utils, for convenience, providing a text
> reader/writer(s) with default or auto-detect or platform-specific line
> ending format(s).
>   

Some application might need this. The base system doesn't.

> Role 2:
>  - a text editor expects a string which having only cr as a line
> ending markers in input string/stream. PERIOD.
>   

That is an error. There is no reason for that. And you saying "PERIOD" 
doesn't change that.

>  - text editor, if requested could convert an edited text from its
> internal representation back into string with cr's, ready to use
> by/for any other means outside of it. PERIOD.
>   

Well, you can add commands for the user to do any conversion. That's not 
a problem.

>  - basically, text editor should not mess with ANY control characters
> beyond its internal representation/needs. PERIOD.
>   

It doesn't have any internal representation needs. That's my whole 
point. It can handle all 3 line endings without any problem at all, as 
it does in Cuis.

Cheers,
Juan Vuletich