support of various line ends in trunk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

support of various line ends in trunk

Stephan Eggermont-3
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. 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.

Stephan Eggermont


Reply | Threaded
Open this post in threaded view
|

Re: support of various line ends in trunk

Juan Vuletich-4
Hi Stephan,

[hidden email] 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.

> Stephan Eggermont

Cheers,
Juan Vuletich

Reply | Threaded
Open this post in threaded view
|

Re: support of various line ends in trunk

Igor Stasenko
2009/11/17 Juan Vuletich <[hidden email]>:

> Hi Stephan,
>
> [hidden email] 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).

Role 2:
 - a text editor expects a string which having only cr as a line
ending markers in input string/stream. PERIOD.
 - 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.
 - basically, text editor should not mess with ANY control characters
beyond its internal representation/needs. PERIOD.


>> Stephan Eggermont
>
> Cheers,
> Juan Vuletich
>


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: support of various line ends in trunk

Juan Vuletich-4
Hi Igor,

Igor Stasenko wrote:

> 2009/11/17 Juan Vuletich <[hidden email]>:
>  
>> Hi Stephan,
>>
>> [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

Re: support of various line ends in trunk

Igor Stasenko
2009/11/17 Juan Vuletich <[hidden email]>:

> Hi Igor,
>
> Igor Stasenko wrote:
>>
>> 2009/11/17 Juan Vuletich <[hidden email]>:
>>
>>>
>>> Hi Stephan,
>>>
>>> [hidden email] 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.
>

Sorry, but i fail to see how text editor implementation, which
constantly operates with the whole string buffer
at any operation (insertion/deletion/navigation & displaying) can be
called efficient.
And from this point, i'm not interested in discussing 'improvements'
like clever line endings, because its simply
not that improvement i'd like to see.

> Cheers,
> Juan Vuletich
>
>



--
Best regards,
Igor Stasenko AKA sig.