About end of line convention

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

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
> [hidden email]
> 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 <[hidden email]> 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
>> [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
>

> 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 <[hidden email]>:
>> 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 <[hidden email]> 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
>>> [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

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