[Pharo-project] About end of line convention
Stéphane Ducasse wrote:
When we edit a file we should be in control about that we want to have. I don't think so. What we want is an end of line. I don't care how it is represented. (Actually, I do. It should be out-of-band instead of a character. But I'm not going to get that). Only when saving/exporting (and importing) can I be interested in the representation. Default should be platform, as most people are not interested in implementation problems.
In CUIS when you edit a file you can decide the convention or change it. I don't like that. It is fine for a hex editor, but not for text.
Stephan Eggermont
IMO, a useful behavior for a text file editor is to: * On open, detect the line end convention of the file and remember it. This is not too hard to do as long as the file is in fact a text file (if it's a binary file you shouldn't be using a text editor on it). * On save, save in the same line end convention that the file previously had. * On "save as" provide the opportunity to change the line end convention as well as the file name. * New files should default to the platform's line end convention, but again be overridable on save. Regards, -Martin
2009/11/20 Martin McClure <martin@hand2mouse.com>:
IMO, a useful behavior for a text file editor is to:
* On open, detect the line end convention of the file and remember it. This is not too hard to do as long as the file is in fact a text file (if it's a binary file you shouldn't be using a text editor on it).
* On save, save in the same line end convention that the file previously had.
* On "save as" provide the opportunity to change the line end convention as well as the file name.
* New files should default to the platform's line end convention, but again be overridable on save.
+1 exactly what i want. + detect if file starting with BOM character, then use utf-8 decoding.
Regards,
-Martin
_______________________________________________ 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.
Yes! Stef
IMO, a useful behavior for a text file editor is to:
* On open, detect the line end convention of the file and remember it. This is not too hard to do as long as the file is in fact a text file (if it's a binary file you shouldn't be using a text editor on it).
* On save, save in the same line end convention that the file previously had.
* On "save as" provide the opportunity to change the line end convention as well as the file name.
* New files should default to the platform's line end convention, but again be overridable on save.
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+1 -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Thursday, November 19, 2009 8:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About end of line convention Yes! Stef
IMO, a useful behavior for a text file editor is to:
* On open, detect the line end convention of the file and remember it. This is not too hard to do as long as the file is in fact a text file (if it's a binary file you shouldn't be using a text editor on it).
* On save, save in the same line end convention that the file previously had.
* On "save as" provide the opportunity to change the line end convention as well as the file name.
* New files should default to the platform's line end convention, but again be overridable on save.
Regards,
-Martin
_______________________________________________ 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
Exactly! +100 FWIW, this us the behaviour of Textpad, my favourite Windoze text editor. -- Cheers, Peter. On 20 nov 2009, at 01.49, Martin McClure <martin@hand2mouse.com> wrote:
IMO, a useful behavior for a text file editor is to:
* On open, detect the line end convention of the file and remember it. This is not too hard to do as long as the file is in fact a text file (if it's a binary file you shouldn't be using a text editor on it).
* On save, save in the same line end convention that the file previously had.
* On "save as" provide the opportunity to change the line end convention as well as the file name.
* New files should default to the platform's line end convention, but again be overridable on save.
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
We must separate the matters. - how should we display the line-feed (independently from their source) - how should the FileList tool handle various conversions (line end, encodings,...) Old squeak and current Pharo both display an ugly [] box in case there is a line feed in a String.
From this point of view, displaying a boxed [lf] in Cuis is already a big progress :), though I did not follow the same path in trunk.
Concerning the file tool, +100 for the reasonnable default behavior on read. But that should not be the sole option. For example, I have plenty of mixed line end conventions files. This is due to people editing the files in heterogeneous environments. You can judge that this is silly, I perfectly agree, but I can't fight. It just exists that's a fact. Once you admit that, the bad players are the applications not handling correctly these mixed conventions files. Squeak/Pharo are bad players when they try to smartly detectLineEndConvention, they are not smart at all and introduce spurious line breaks when they write back with same guessed convention. That's why I HAVE TO be able to CONTROL the read behaviour too, and not let smart tools decide for me. Transparent line end is one of the options. As noticed by Igor, same for encodings of course. As for the display, my opinion is that most of the time we just don't want to see the line endings. That's why I changed this in trunk to be transparent (more exactly as transparent if following a cr, as a line break otherwise) This enables to not care at all for converting external world input->image in most cases. I still have to care about converting image->output to external world, though, I think we all agree on that, so +100 too for the save as proposals (hehe, I also have some cases when I do not care at all, because I have a smart tool chain handling mixed conventions, so again transparent will be an option). In some particular situations we do care and wish to visually control the line ends. An hex editor is not that fine because we are speaking of text here, not binary data, and an hex editor generally fails to interpret the line breaks and leads to hardly readable data. I personnally use notepad++ and change a display parameter to show [cr] [lf] boxes. That's what Juan is addressing in Cuis, and I think it would be simple to incorporate this feature as another option in the file browser, so we could eventually do it. Anyway, I agree, not as the default behavior... All in all, I think we mostly agree, and should reach a consensus. cheers Nicolas 2009/11/20 Peter Hugosson-Miller <oldmanlink@gmail.com>:
Exactly! +100
FWIW, this us the behaviour of Textpad, my favourite Windoze text editor.
-- Cheers, Peter.
On 20 nov 2009, at 01.49, Martin McClure <martin@hand2mouse.com> wrote:
IMO, a useful behavior for a text file editor is to:
* On open, detect the line end convention of the file and remember it. This is not too hard to do as long as the file is in fact a text file (if it's a binary file you shouldn't be using a text editor on it).
* On save, save in the same line end convention that the file previously had.
* On "save as" provide the opportunity to change the line end convention as well as the file name.
* New files should default to the platform's line end convention, but again be overridable on save.
Regards,
-Martin
_______________________________________________ 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
Ok I read everything. Igor I agree with you about not showing tags but the system still show [] and let me import [lf] files and fucked up my code. Each time I save VW code to import it into pharo I have to run some scripts to clean that. Here is what I understood - could we try to make sure that when something is loaded in the image it by default follow image convention? For example I fill in a cs that contains lf I should get something consistent in the image - would be nice to see [lf] instead of [] and remove all of them from the image - for filelist would be nice to see and be able to change the end of the line character - Now I was wondering what is the status at the level of the stream? Ie can I load a file which has lf and say stream convertLFToCr? Stef
We must separate the matters. - how should we display the line-feed (independently from their source) - how should the FileList tool handle various conversions (line end, encodings,...)
Old squeak and current Pharo both display an ugly [] box in case there is a line feed in a String. From this point of view, displaying a boxed [lf] in Cuis is already a big progress :), though I did not follow the same path in trunk.
Concerning the file tool, +100 for the reasonnable default behavior on read. But that should not be the sole option.
For example, I have plenty of mixed line end conventions files. This is due to people editing the files in heterogeneous environments. You can judge that this is silly, I perfectly agree, but I can't fight. It just exists that's a fact. Once you admit that, the bad players are the applications not handling correctly these mixed conventions files. Squeak/Pharo are bad players when they try to smartly detectLineEndConvention, they are not smart at all and introduce spurious line breaks when they write back with same guessed convention.
That's why I HAVE TO be able to CONTROL the read behaviour too, and not let smart tools decide for me. Transparent line end is one of the options. As noticed by Igor, same for encodings of course.
As for the display, my opinion is that most of the time we just don't want to see the line endings. That's why I changed this in trunk to be transparent (more exactly as transparent if following a cr, as a line break otherwise) This enables to not care at all for converting external world input->image in most cases. I still have to care about converting image->output to external world, though, I think we all agree on that, so +100 too for the save as proposals (hehe, I also have some cases when I do not care at all, because I have a smart tool chain handling mixed conventions, so again transparent will be an option).
In some particular situations we do care and wish to visually control the line ends. An hex editor is not that fine because we are speaking of text here, not binary data, and an hex editor generally fails to interpret the line breaks and leads to hardly readable data. I personnally use notepad++ and change a display parameter to show [cr] [lf] boxes. That's what Juan is addressing in Cuis, and I think it would be simple to incorporate this feature as another option in the file browser, so we could eventually do it. Anyway, I agree, not as the default behavior...
All in all, I think we mostly agree, and should reach a consensus.
cheers
Nicolas
2009/11/20 Peter Hugosson-Miller <oldmanlink@gmail.com>:
Exactly! +100
FWIW, this us the behaviour of Textpad, my favourite Windoze text editor.
-- Cheers, Peter.
On 20 nov 2009, at 01.49, Martin McClure <martin@hand2mouse.com> wrote:
IMO, a useful behavior for a text file editor is to:
* On open, detect the line end convention of the file and remember it. This is not too hard to do as long as the file is in fact a text file (if it's a binary file you shouldn't be using a text editor on it).
* On save, save in the same line end convention that the file previously had.
* On "save as" provide the opportunity to change the line end convention as well as the file name.
* New files should default to the platform's line end convention, but again be overridable on save.
Regards,
-Martin
_______________________________________________ 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
On 20.11.2009 22:30, Nicolas Cellier wrote:
We must separate the matters. - how should we display the line-feed (independently from their source) - how should the FileList tool handle various conversions (line end, encodings,...)
Old squeak and current Pharo both display an ugly [] box in case there is a line feed in a String.
From this point of view, displaying a boxed [lf] in Cuis is already a big progress :), though I did not follow the same path in trunk.
Concerning the file tool, +100 for the reasonnable default behavior on read. But that should not be the sole option.
For example, I have plenty of mixed line end conventions files. This is due to people editing the files in heterogeneous environments. You can judge that this is silly, I perfectly agree, but I can't fight. It just exists that's a fact. Once you admit that, the bad players are the applications not handling correctly these mixed conventions files. Squeak/Pharo are bad players when they try to smartly detectLineEndConvention, they are not smart at all and introduce spurious line breaks when they write back with same guessed convention.
That's why I HAVE TO be able to CONTROL the read behaviour too, and not let smart tools decide for me. Transparent line end is one of the options. As noticed by Igor, same for encodings of course.
As for the display, my opinion is that most of the time we just don't want to see the line endings. That's why I changed this in trunk to be transparent (more exactly as transparent if following a cr, as a line break otherwise) This enables to not care at all for converting external world input->image in most cases. I still have to care about converting image->output to external world, though, I think we all agree on that, so +100 too for the save as proposals (hehe, I also have some cases when I do not care at all, because I have a smart tool chain handling mixed conventions, so again transparent will be an option).
In some particular situations we do care and wish to visually control the line ends. An hex editor is not that fine because we are speaking of text here, not binary data, and an hex editor generally fails to interpret the line breaks and leads to hardly readable data. I personnally use notepad++ and change a display parameter to show [cr] [lf] boxes. That's what Juan is addressing in Cuis, and I think it would be simple to incorporate this feature as another option in the file browser, so we could eventually do it. Anyway, I agree, not as the default behavior...
All in all, I think we mostly agree, and should reach a consensus.
cheers
Nicolas
+1000 If I'd had time to write a reply to the topic, this post would be i, so thanks for writing it already. :) Cheers, Henry
On Nov 20, 2009, at 1:39 AM, Stephan Eggermont wrote:
Stéphane Ducasse wrote:
When we edit a file we should be in control about that we want to have. I don't think so. What we want is an end of line. I don't care how it is represented.
Most of the time. But when you need to know this is important to know it.
(Actually, I do. It should be out-of-band instead of a character. But I'm not going to get that). Only when saving/exporting (and importing) can I be interested in the representation. Default should be platform, as most people are not interested in implementation problems.
Yes probably.
In CUIS when you edit a file you can decide the convention or change it. I don't like that. It is fine for a hex editor, but not for text.
why if by default you get your default platform?
Stephan Eggermont _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Henrik Sperre Johansen -
Igor Stasenko -
Martin McClure -
Nicolas Cellier -
Peter Hugosson-Miller -
Schwab,Wilhelm K -
Stephan Eggermont -
Stéphane Ducasse