[Pharo-project] About end of line convention
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? Stef
2009/11/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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.
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??? 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. If i would want to see a binary contents of file, i use hex dump display/edit, but not text editor. (see another attachment) 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.
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. 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#a62...
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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#a62...
No time for that now.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/11/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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.
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'. 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#a62...
No time for that now.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2009/11/20 Igor Stasenko <siguctua@gmail.com>:
2009/11/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 ? cheers Nicolas
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#a62...
No time for that now.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/11/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2009/11/20 Igor Stasenko <siguctua@gmail.com>:
2009/11/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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.
Hi guys, I think a renderer or editor should be completely unaware about the underlying format of a file. A renderer could be concerned about text drawing, glyphs buffering (when appropiate, i.e. non-latin scripts), display maintenance when scrolling, colouring, etc. An editor should manage searching data, editing large files, keyboard input, etc. But... if computer gurus of the ' 70 invented 6 forms of end-of-line, one per operating system, and they didn't thought in terms of objects, let's leave it there. Conceptually end-of-line, line-breaks, form-feeds, line-separators and other control codes are computer artifacts necessary to format natural language text. They reveal an intention of a human to separate blocks of text semantically. But AFAIK there is no end-of-line grapheme in natural human languages, and so this inheritance from the ´70 should be as isolated as possible, let's use an intuitionistic logic in a clever way and everything would become clear :) A formatter object, separated from rendering and editing, should end in a clean implementation. Using a formatter or another is a matter of the role of the human or the tool working with the file contents (it's so hard to assume things about humans...), but to me, Smalltalk should not be married anymore with the historical problems of others. Cheers, Hernán 2009/11/20 Igor Stasenko <siguctua@gmail.com>:
2009/11/20 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2009/11/20 Igor Stasenko <siguctua@gmail.com>:
2009/11/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/11/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks It makes sense to me. I like to have a good default and give the power to the programmer. Stef On Nov 20, 2009, at 7:39 PM, Nicolas Cellier wrote:
2009/11/20 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Hernán Morales Durand -
Igor Stasenko -
Nicolas Cellier -
Philippe Marschall -
Stéphane Ducasse