> El 2 jun 2019, a las 20:45, ducasse <steph...@netcourrier.com> escribió:
>
> Sven
>
> why not having this as extension.
I’d even propose to have it by default: a FileReference writeStream can return
a ZnNewLineWriterStream wrapping the corresponding stream.
By default it can be configured with the system’s default line ending
convention (least surprise?).
And then users can change it accordingly…
Now I ask also myself what we could do when reading line endings from a file.
I’m 98.761% convinced that in the image we should have a single line ending
convention for strings, and that we should convert internal strings to the
external representation of convenience explicitly.
In this direction we could make that default read streams in FileSystem to
automatically transform external line endings into internal line endings.
>
> Stef
>
>
>> On 2 Jun 2019, at 13:52, Alistair Grant <akgrant0...@gmail.com> wrote:
>>
>> Hi Ben,
>>
>> On Fri, 31 May 2019 at 07:08, Ben Coman <b...@openinworld.com> wrote:
>>>
>>>
>>> I'm on Windows wanting to write a text file with LF endings.
>>> The code developed on Linux is thus...
>>> (destinationDirectory / 'README.md') ensureCreateFile
>>> writeStreamDo: [ :stream | stream nextPutAll: class comment ]
>>
>> I've come across this so many times that I always add a couple of
>> methods to my image:
>>
>> ZnEncodedStream>>asNewLineStream
>> "Answer the receiver wrapped with a ZnNewLineWriterStream"
>> ^ZnNewLineWriterStream on: self! !
>>
>>
>> ZnNewLineWriterStream>>asNewLineStream
>> "Answer the receiver wrapped with a ZnNewLineWriterStream"
>> ^self! !
>>
>>
>> You could then modify the example above to be:
>>
>> stream asNewLineStream forLf nextPutAll: class comment
>>
>> Cheers,
>> Alistair
>>
>>
>>
>>> and I am stuck with CR line endings.
>>> The specific symptom is that it screws `git diff`
>>> Here is a simple experiment...
>>> testfile := 'README.md' asFileReference.
>>> testfile ensureCreateFile writeStreamDo: [ :stream |
>>> stream nextPutAll: 'aa
>>> bb' ].
>>> testfile binaryReadStream contents at: 3 "==> Character cr "
>>>
>>> I think its safe to assume on Linux that will result in "==> Character lf "
>>> but can someone please confirm?
>>>
>>> So my issue is that I've got
>>> #ensureCreateFile - returns a FileReference
>>> and
>>> :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream
>>> wrapping BinaryFileStream.
>>>
>>> and neither seem to have an easily accessible defaultLineEnding setting.
>>> Indeed, line endings are not a property of FileReference
>>> and Binary & Characters have nothing to do with line endings,
>>> and questionable if Buffering is related.
>>>
>>> Its more a property of a File, but IIUC that is being deprecated (??)
>>>
>>> MultiByteFileStream has #lineEndConvention:
>>> but IIUC that also is being deprecated.
>>>
>>> So what is the proper way to force default line endings?
>>>
>>>
>>> ------
>>> Now while composing this email I discovered String>>withUnixLineEndings.
>>> So I have a solution...
>>> testfile := 'README.md' asFileReference.
>>> testfile ensureCreateFile writeStreamDo: [ :stream |
>>> stream nextPutAll: 'aa
>>> bb' withUnixLineEndings ].
>>> (testfile binaryReadStream contents at: 3) asCharacter "==> Character
>>> lf "
>>>
>>> but that seems to imply that on Windows...
>>> 'aa
>>> bb' at: 3 "==> Character cr "
>>>
>>> and on Linux (someone please confirm)...
>>> 'aa
>>> bb' at: 3 "==> Character lf "
>>>
>>> and that is *very* curious. Strange that I never noticed it before and
>>> obviously that hasn't hurt me,
>>> but considering the Principal Of Least Surprise it leaves me feeling
>>> somewhat violated :)
>>
>
>
>
