Yes, maybe. These kind of convenience messages are cool, but it feels that many would be needed, and together they will form a heavy protocol by themselves, making it harder to implement a new stream from scratch.
> On 2 Jun 2019, at 20:45, ducasse <[email protected]> wrote: > > Sven > > why not having this as extension. > > Stef > > >> On 2 Jun 2019, at 13:52, Alistair Grant <[email protected]> wrote: >> >> Hi Ben, >> >> On Fri, 31 May 2019 at 07:08, Ben Coman <[email protected]> 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 :) >> > > >
