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.

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!).

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.

> Cheers,
> Juan Vuletich
>
>



-- 
Best regards,
Igor Stasenko AKA sig.