So one step at a time:

- #cr and #lf just put this character in the stream.
- #newLine put the underlying OS line ending. ( and sorry for the
nostalgic but nl sucks and to me this is netherlands and not newline
:).

Then we should revisit all the cr inside the system and use newline.
Then we should think about the internal usage of cr by default in
Pharo (We should change it).

Does it make sense?
Stef



On Sat, Aug 5, 2017 at 4:08 PM, K K Subbu <kksubbu...@gmail.com> wrote:
> On Friday 04 August 2017 07:11 PM, Damien Pollet wrote:
>>
>> Stream >> newLineFor: platform
>>      self nextPutAll: platform lineEnding
>>
>
> EOL encoding is a property of a text file and not a platform. While files
> created on a certain proprietary platforms ;-) may use an encoding that does
> not make it a platform property. Pharo should be liberal in accepting and
> preserving differently encoded files. E.g. Text editor vim has a setting
> (fileformats) for eol encoding to view or edit files with cr or crlf EOL
> encoding. If this is not set, vim falls back to nl.
>
> I agree that existing messages like cr or nl should not be changed. Instead
> new methods (*eol) could be added to text files for decoding (read side) and
> encoding (write side). This should be liberal in accepting cr, nl, crnl
> decodes while reading a text file. While writing a new stream, eol should
> follow this order:
>       1. if file eol property is set (cr/nl/crnl) it should use it
>       2. else fallback to check platform eol property.
>       3. Else, use cr (for backward compatibility with old files)
> E.g.
>
>  (aStream atEOL) ifFalse: [ c := aStream next ]
>  aStream nextPutAll: 'hello world' ; writeEOL
>  record := aStream readLine. "strip eol"
>  aStream nextPutLine: 'hello world'
>
> This is not going to be an easy change but it would make new code cleaner.
>
> Regards .. Subbu
>

Reply via email to