[squeak-dev] support of various line ends in trunk

Igor Stasenko siguctua at gmail.com
Tue Nov 17 14:07:02 UTC 2009


2009/11/17 Juan Vuletich <juan at jvuletich.org>:
> 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.
>

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.



More information about the Squeak-dev mailing list