About end of line convention

> Instead, import should deal with
> normalizing the input to a form, edigible by editor, and then export
> layer (file-out or whatever) may be instructed to save edited file
> using one or other line-ends, but editor should use own convention(s)
> and free to choose own ways how internally store the edited text.
>
>> My point of view on this is :
>>        - when I manipulate the text object may be we should have the platform convention.
>>        - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>
>> So nicolas I saw that you pushed a slice about fixing end of line.
>> What is the design behind it?
>>
>
> Stef, you can always read a full discussion about it on squeak-dev archives.
> http://n4.nabble.com/support-of-various-line-ends-in-trunk-td622338.html#a622338

>
>> Stef
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
> <text.txt><cuis-editor.png><hexdump.png>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>>
>> The way how CIUS solves this shown at screenshot.
>>
>> My humble question:
>> if i created a text file, what you think is more important to me:
>>  - being able to clearly read the text
>>  - or being able to see all control characters which may differ from
>> OS to OS???
>
> sorry but you are wrong.
> I saw how this is done in CUIS and if you want to see the end line character
> you can see them, else not.
> I'm often burned with not having that and I think that his solution is cool.
>
>> My line of argumentation is, that text editor should serve for editing
>> a text, but not some sort of binary-mode editing
>> where text is a mix of usual symbols and non-human stuff, which having
>> meaning only to computer.
>
> No
>
>> If i would want to see a binary contents of file, i use hex dump
>> display/edit, but not text editor.
>> (see another attachment)
>
> No
>
>> Use right tool for things you do. By making a single tool for serving
>> everything - as result you getting a horrific & complex monster
>> without any means how to manage it and improve.
>
> No
>
>>
>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>
>> This is not correct.
>> I am pushing the idea, that text editor should serve to edit and
>> display text, and don't care about preserving or dealing with
>> different line-end conventions.
>
> Then you did not got burn enough by moving files between OSes
> I regularly spent time with tr on unix just to clean such kind of things.
>

>> Instead, import should deal with
>> normalizing the input to a form, edigible by editor, and then export
>> layer (file-out or whatever) may be instructed to save edited file
>> using one or other line-ends, but editor should use own convention(s)
>> and free to choose own ways how internally store the edited text.
>>
>>> My point of view on this is :
>>>        - when I manipulate the text object may be we should have the platform convention.
>>>        - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>>
>>> So nicolas I saw that you pushed a slice about fixing end of line.
>>> What is the design behind it?
>>>
>>
>> Stef, you can always read a full discussion about it on squeak-dev archives.
>> http://n4.nabble.com/support-of-various-line-ends-in-trunk-td622338.html#a622338
>
> No time for that now.
>
>>
>>> Stef
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>> <text.txt><cuis-editor.png><hexdump.png>_______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Hi nicolas
>
> I was dicussing today with juan vuletich about the management of end of line convention and I think that
> he is right. When we edit a file we should be in control about that we want to have.
> In CUIS when you edit a file you can decide the convention or change it.
> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
> My point of view on this is :
> - when I manipulate the text object may be we should have the platform convention.
> - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>
> So nicolas I saw that you pushed a slice about fixing end of line.
> What is the design behind it?

> Stéphane Ducasse wrote:
>> Hi nicolas
>>
>> I was dicussing today with juan vuletich about the management of end of line convention and I think that
>> he is right. When we edit a file we should be in control about that we want to have.
>> In CUIS when you edit a file you can decide the convention or change it.
>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>> My point of view on this is :
>> - when I manipulate the text object may be we should have the platform convention.
>> - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>
>> So nicolas I saw that you pushed a slice about fixing end of line.
>> What is the design behind it?
>
> End of line convention in which context? The changes file? File outs?
> File streams?
>
> Cheers
> Philippe
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> On Nov 20, 2009, at 6:09 PM, Philippe Marschall wrote:
>
>> Stéphane Ducasse wrote:
>>> Hi nicolas
>>>
>>> I was dicussing today with juan vuletich about the management of end of line convention and I think that
>>> he is right. When we edit a file we should be in control about that we want to have.
>>> In CUIS when you edit a file you can decide the convention or change it.
>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>> My point of view on this is :
>>>      - when I manipulate the text object may be we should have the platform convention.
>>>      - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>>
>>> So nicolas I saw that you pushed a slice about fixing end of line.
>>> What is the design behind it?
>>
>> End of line convention in which context? The changes file? File outs?
>> File streams?
>>
>> Cheers
>> Philippe
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 2009/11/20 Stéphane Ducasse <[hidden email]>:
>> It was more on file streams or text when you edit a file.
>> In particular this was in context of
>>        http://code.google.com/p/pharo/issues/detail?id=1458
>>
>> Because before integrating it I wanted to know what it was about.
>>
>> Stef
>>
>
> Hi Stephane,
>
> These changes just make it possible to handle various line delimiters
> for splitting lines in a String.
>
> Discussion was lengthy in trunk about whether or not these various
> line delimiters should have made their path inside the image.
> Some would prefer to stick to simple st-80 cr-only handling in image
> and carry ALL the conversions at read/write to the complex external
> world.
> The rationale is that complexity should not enter the image.
>
> My POV differs.
>
> 1) because handling cr-lf-crlf in image is not that complex (judge how
> complex is the new code versus the old one)
> 2) because it is not CPU intensive (The line splitting methods were
> not optimized, thus I reduced the cost of splitting, and therefore, I
> reject the argument that it does matter that much)
> 3) because making the right decision about conversion can depend on
> applications and can be complex, that's why it should ultimately be in
> the hands of programmer.
>
> I see no contradiction in using detectLineEndConventions in Pharo tools.
> Though the current algorithm fail to handle mixed-conventions files
> correctly, that's a good default policy.
> But this simple trick can NOT handle ALL the cases (the
> mixed-conventions is an example).
>
> A universal line end converter fitting all possible use cases does not
> exist and would be more than complex.
> Let the grown up programmer decide what better fits his application
> and provide decent tools to him (her).
>
> If you decide to reject these modifications, then please revert
> http://code.google.com/p/pharo/issues/detail?id=1356 for consistency.
>
> cheers
>
> Nicolas
>
>
>> On Nov 20, 2009, at 6:09 PM, Philippe Marschall wrote:
>>
>>> Stéphane Ducasse wrote:
>>>> Hi nicolas
>>>>
>>>> I was dicussing today with juan vuletich about the management of end of line convention and I think that
>>>> he is right. When we edit a file we should be in control about that we want to have.
>>>> In CUIS when you edit a file you can decide the convention or change it.
>>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>>> My point of view on this is :
>>>>      - when I manipulate the text object may be we should have the platform convention.
>>>>      - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>>>
>>>> So nicolas I saw that you pushed a slice about fixing end of line.
>>>> What is the design behind it?
>>>
>>> End of line convention in which context? The changes file? File outs?
>>> File streams?
>>>
>>> Cheers
>>> Philippe
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 2009/11/20 Stéphane Ducasse <[hidden email]>:
>>>
>>> The way how CIUS solves this shown at screenshot.
>>>
>>> My humble question:
>>> if i created a text file, what you think is more important to me:
>>>  - being able to clearly read the text
>>>  - or being able to see all control characters which may differ from
>>> OS to OS???
>>
>> sorry but you are wrong.
>> I saw how this is done in CUIS and if you want to see the end line character
>> you can see them, else not.
>> I'm often burned with not having that and I think that his solution is cool.
>>
>>> My line of argumentation is, that text editor should serve for editing
>>> a text, but not some sort of binary-mode editing
>>> where text is a mix of usual symbols and non-human stuff, which having
>>> meaning only to computer.
>>
>> No
>>
>>> If i would want to see a binary contents of file, i use hex dump
>>> display/edit, but not text editor.
>>> (see another attachment)
>>
>> No
>>
>>> Use right tool for things you do. By making a single tool for serving
>>> everything - as result you getting a horrific & complex monster
>>> without any means how to manage it and improve.
>>
>> No
>>
>>>
>>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>>
>>> This is not correct.
>>> I am pushing the idea, that text editor should serve to edit and
>>> display text, and don't care about preserving or dealing with
>>> different line-end conventions.
>>
>> Then you did not got burn enough by moving files between OSes
>> I regularly spent time with tr on unix just to clean such kind of things.
>>

> Squeak's text editor allows you to do some formatting, like changing
> font, emphasis, color and more special things like links etc..
> And once you changing text using this, you can't represent it as
> plaing text without losing formatting information, and from that point
> preserving line ends becoming too minor issue comparing to fact that
> you can't preserve formatting.
>
> As to me, from this side, a text editor behaves like html renderer,
> while displaying control characters is analoguous to displaying html
> source instead of rendering it. Now tell me, have you seen html
> renderer , which instead of rendering page - showing you tags?
>

> Or if you prefer to see html source, then it is logical to diplay all
> other kinds of formatting with plain text (by using some kind of
> markup), instead of reflecting them visually. No?
>
> And then, don't you think that rendering html and displaying html is
> done using different tools, because obviously it is two different
> representations of same document. And nobody mixing them (you don't
> see any tags when browsing, while can see them when looking at
> source), while Juan's modification looks like a mixture of two
> different modes - 'raw' mode, when you can see source and rendering
> mode - when you see the designed document.
>
> Such kind of mixture is awfully wrong. So, if you want to see line
> feeds in text, then get rid of text formatting features first,
> or make two SEPARATE TOOLS, each specialized on different displaying mode.
>

>>> Instead, import should deal with
>>> normalizing the input to a form, edigible by editor, and then export
>>> layer (file-out or whatever) may be instructed to save edited file
>>> using one or other line-ends, but editor should use own convention(s)
>>> and free to choose own ways how internally store the edited text.
>>>
>>>> My point of view on this is :
>>>>        - when I manipulate the text object may be we should have the platform convention.
>>>>        - when I edit a file I should get the control because I may want to edit a file on mac with unix convention.
>>>>
>>>> So nicolas I saw that you pushed a slice about fixing end of line.
>>>> What is the design behind it?
>>>>
>>>
>>> Stef, you can always read a full discussion about it on squeak-dev archives.
>>> http://n4.nabble.com/support-of-various-line-ends-in-trunk-td622338.html#a622338
>>
>> No time for that now.
>>
>>>
>>>> Stef
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>> <text.txt><cuis-editor.png><hexdump.png>_______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 2009/11/20 Igor Stasenko <[hidden email]>:
>> 2009/11/20 Stéphane Ducasse <[hidden email]>:
>>>>
>>>> The way how CIUS solves this shown at screenshot.
>>>>
>>>> My humble question:
>>>> if i created a text file, what you think is more important to me:
>>>>  - being able to clearly read the text
>>>>  - or being able to see all control characters which may differ from
>>>> OS to OS???
>>>
>>> sorry but you are wrong.
>>> I saw how this is done in CUIS and if you want to see the end line character
>>> you can see them, else not.
>>> I'm often burned with not having that and I think that his solution is cool.
>>>
>>>> My line of argumentation is, that text editor should serve for editing
>>>> a text, but not some sort of binary-mode editing
>>>> where text is a mix of usual symbols and non-human stuff, which having
>>>> meaning only to computer.
>>>
>>> No
>>>
>>>> If i would want to see a binary contents of file, i use hex dump
>>>> display/edit, but not text editor.
>>>> (see another attachment)
>>>
>>> No
>>>
>>>> Use right tool for things you do. By making a single tool for serving
>>>> everything - as result you getting a horrific & complex monster
>>>> without any means how to manage it and improve.
>>>
>>> No
>>>
>>>>
>>>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>>>
>>>> This is not correct.
>>>> I am pushing the idea, that text editor should serve to edit and
>>>> display text, and don't care about preserving or dealing with
>>>> different line-end conventions.
>>>
>>> Then you did not got burn enough by moving files between OSes
>>> I regularly spent time with tr on unix just to clean such kind of things.
>>>
>
> Hi Igor
>
>>
>> Trust me, i burnt to the point that i don't want to see or hear about
>> them again in my life. And Juan's editor displaying 'lf' glyphs is
>> like 'wellcome back, to hell'.
>>
>
> Just what [] box are currently :) but a bit more informative.
> Don't flame me, I don't support this feature as a reasonnable default.
>
>> Squeak's text editor allows you to do some formatting, like changing
>> font, emphasis, color and more special things like links etc..
>> And once you changing text using this, you can't represent it as
>> plaing text without losing formatting information, and from that point
>> preserving line ends becoming too minor issue comparing to fact that
>> you can't preserve formatting.
>>
>> As to me, from this side, a text editor behaves like html renderer,
>> while displaying control characters is analoguous to displaying html
>> source instead of rendering it. Now tell me, have you seen html
>> renderer , which instead of rendering page - showing you tags?
>>
>
> +1
> So I'm happy to notice you should agree on my modification for
> rendering linefeed transparently in trunk.
>

>> Or if you prefer to see html source, then it is logical to diplay all
>> other kinds of formatting with plain text (by using some kind of
>> markup), instead of reflecting them visually. No?
>>
>> And then, don't you think that rendering html and displaying html is
>> done using different tools, because obviously it is two different
>> representations of same document. And nobody mixing them (you don't
>> see any tags when browsing, while can see them when looking at
>> source), while Juan's modification looks like a mixture of two
>> different modes - 'raw' mode, when you can see source and rendering
>> mode - when you see the designed document.
>>
>> Such kind of mixture is awfully wrong. So, if you want to see line
>> feeds in text, then get rid of text formatting features first,
>> or make two SEPARATE TOOLS, each specialized on different displaying mode.
>>
>
> Good sense of logic, that's a smart demonstration.
> But we have to be pragmatic too.
> If we limit this feature to poor text editors (character files), the
> demonstration about rich text does not really apply.
> Be it an option or a separate tool does not really matter. Notepad++
> and lot of other string editors have this as an option.
> As long as it is an option in FileList tool and not the main
> behaviour, I think you could tolerate it, couldn't you ?
>

> 2009/11/20 Nicolas Cellier <[hidden email]>:
>> 2009/11/20 Igor Stasenko <[hidden email]>:
>>> 2009/11/20 Stéphane Ducasse <[hidden email]>:
>>>>>
>>>>> The way how CIUS solves this shown at screenshot.
>>>>>
>>>>> My humble question:
>>>>> if i created a text file, what you think is more important to me:
>>>>>  - being able to clearly read the text
>>>>>  - or being able to see all control characters which may differ from
>>>>> OS to OS???
>>>>
>>>> sorry but you are wrong.
>>>> I saw how this is done in CUIS and if you want to see the end line character
>>>> you can see them, else not.
>>>> I'm often burned with not having that and I think that his solution is cool.
>>>>
>>>>> My line of argumentation is, that text editor should serve for editing
>>>>> a text, but not some sort of binary-mode editing
>>>>> where text is a mix of usual symbols and non-human stuff, which having
>>>>> meaning only to computer.
>>>>
>>>> No
>>>>
>>>>> If i would want to see a binary contents of file, i use hex dump
>>>>> display/edit, but not text editor.
>>>>> (see another attachment)
>>>>
>>>> No
>>>>
>>>>> Use right tool for things you do. By making a single tool for serving
>>>>> everything - as result you getting a horrific & complex monster
>>>>> without any means how to manage it and improve.
>>>>
>>>> No
>>>>
>>>>>
>>>>>> He told me that in the squeak world people were pushing that the end of line is controlled by the platform.
>>>>>
>>>>> This is not correct.
>>>>> I am pushing the idea, that text editor should serve to edit and
>>>>> display text, and don't care about preserving or dealing with
>>>>> different line-end conventions.
>>>>
>>>> Then you did not got burn enough by moving files between OSes
>>>> I regularly spent time with tr on unix just to clean such kind of things.
>>>>
>>
>> Hi Igor
>>
>>>
>>> Trust me, i burnt to the point that i don't want to see or hear about
>>> them again in my life. And Juan's editor displaying 'lf' glyphs is
>>> like 'wellcome back, to hell'.
>>>
>>
>> Just what [] box are currently :) but a bit more informative.
>> Don't flame me, I don't support this feature as a reasonnable default.
>>
>>> Squeak's text editor allows you to do some formatting, like changing
>>> font, emphasis, color and more special things like links etc..
>>> And once you changing text using this, you can't represent it as
>>> plaing text without losing formatting information, and from that point
>>> preserving line ends becoming too minor issue comparing to fact that
>>> you can't preserve formatting.
>>>
>>> As to me, from this side, a text editor behaves like html renderer,
>>> while displaying control characters is analoguous to displaying html
>>> source instead of rendering it. Now tell me, have you seen html
>>> renderer , which instead of rendering page - showing you tags?
>>>
>>
>> +1
>> So I'm happy to notice you should agree on my modification for
>> rendering linefeed transparently in trunk.
>>
>
> And i appreciate that.
> I just think that conceptually, putting code which handling line feeds
> in editor or renderer code is wrong.
> Line feeds should be wiped out (converted) before passing to renderer/editor.
>
>>> Or if you prefer to see html source, then it is logical to diplay all
>>> other kinds of formatting with plain text (by using some kind of
>>> markup), instead of reflecting them visually. No?
>>>
>>> And then, don't you think that rendering html and displaying html is
>>> done using different tools, because obviously it is two different
>>> representations of same document. And nobody mixing them (you don't
>>> see any tags when browsing, while can see them when looking at
>>> source), while Juan's modification looks like a mixture of two
>>> different modes - 'raw' mode, when you can see source and rendering
>>> mode - when you see the designed document.
>>>
>>> Such kind of mixture is awfully wrong. So, if you want to see line
>>> feeds in text, then get rid of text formatting features first,
>>> or make two SEPARATE TOOLS, each specialized on different displaying mode.
>>>
>>
>> Good sense of logic, that's a smart demonstration.
>> But we have to be pragmatic too.
>> If we limit this feature to poor text editors (character files), the
>> demonstration about rich text does not really apply.
>> Be it an option or a separate tool does not really matter. Notepad++
>> and lot of other string editors have this as an option.
>> As long as it is an option in FileList tool and not the main
>> behaviour, I think you could tolerate it, couldn't you ?
>>
>
> I am fairly looking from pragmatic point: Don't left line ends mess
> enter the image.
>
> If you want to see them when browsing files in file list - fine.
> I just curious, how useful it is, since there is a plenty of other
> tools in OS(es) which allow you do same (browsing file system +
> viewing file contents), but in much more convenient manner. Maybe it
> hurts someone's feelings, but i think that file list tool is thing
> which too far from one which can called usable. It is simple, and lets
> you view and open files, but i using it only when i need something to
> be loaded into image , and i am always know what file(s) i want to
> load before opening file list tool. And i closing file list
> immediately after loading necessary files, and never using it to
> search for files or browse the file system, simply because i'm not a
> masochist.
>
> But lets get back to editor:
> i have no idea for what purpose this mess (cr/lf) should get past the
> import barriers and appear inside browser or workspace. Anyone wants
> to deal with such mess there?
> So, here is straightly pragmatic point: leave this mess where it came
> from - ouside world.
>
> A plain text is not a bitmap image, which requires a bit-identical
> rendering and color matching and as soon as it is readable, there is
> nothing else we need.
>
> As a last sidenote: i really like how HTML standard deals with it: it
> treats any control characters as a white space - be it space, cr, lf,
> tab etc, and using a markup for indicating line breaks or new
> paragraphs.
> This makes renderer to be completely agnostic from weirdness, which
> comes from ancient terminal-based ages.
>
>> cheers
>>
>> Nicolas
>>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project