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

Igor Stasenko siguctua at gmail.com
Tue Nov 17 13:49:05 UTC 2009


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

There are a binary editors which allowing you to change byte by byte
using hex values.
But since we are talking about text editor, it is meant for editing a
text, but not literally Strings or control characters.
So, if you want a String editor, which allows you to
insert/remove/replace any character at any position - you can
implement it. But then i think you can just use an inspector.

String is not Text. If we are talking about editing text, please stop
talking about control characters as well as Strings, because obviously
text is not only about strings and control chars, its also about
formatting (font, color, alignment etc) and many other things..
You won't be able to represent the text as a media (including for
editing) if your abstraction stops at the point of having control
characters only. What control character should represent an image? and
what is for link?
It is easy to see that control chars doesn't help you with that, they
should live where they belong to - in a files, where text is converted
from live objects into a file using specific binary format
(XML/HTML/PDF/plain text/choose yours).
That's where we could choose one or another line endings etc.. but not
in text editor, which is a nonsense because it deals with live
objects.

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

Hmm.. i was always thinking that text editor is for editing the text,
not Strings. :)
Look, we write tools for users, but not for machine.
Same as we should invent languages to serve for developers, not for compilers.

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

Sorry, you seem misunderstood. Text internal representation is
completely irrelevant.
I just said, that cr char is ok to me as an internal end-of-line
marker and i don't see any reason why we should change that. It is an
implementation detail.
Internally,You could use any other character to mark the line ends, as
well as you can keep a collection of lines for editing, instead using
of a single buffer , then you don't need a line separators at all.

>>> Cheers,
>>> Juan Vuletich
>
> Cheers,
> Juan Vuletich
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list