First, we should not confuse "writing into a stream" with "writing into a
text file". Not all streams are to write into a text file. This means that
we cannot pretend that the basic stream implementation should always do a
conversion. I think that should belong to a text writer, also managing the
text encoding (utf-8 and so on). So far we have a Character writer stream
that wraps a binary stream and manages encoding (see
ZnCharacterWriteStream). I wrote for backwards compatibility
a ZnCrPortableWriteStream (that is in pharo repo so far because but should
be pushed back to Zinc's repo, hi Sven :) ) that manages crlf automatic
Moreover, for people that want "detection of line separators in a file"
such as it is done in text editors, I believe we need a higher level
abstraction. We need also to detect encoding and keep living during the
life of the file. However, we don't have such abstraction.
On Sat, Aug 5, 2017 at 8:03 PM, Alistair Grant <akgrant0...@gmail.com>
> Hi Stef,
> On 5 August 2017 at 18:14, Stephane Ducasse <stepharo.s...@gmail.com>
> > 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
> > :).
> Beyond the nostalgic and humorous, there is actually a justification
> for the shorter #nl.
> Adding a new line is a common operation, and more compact code is more
> readable. So I find:
> << 'Line 1 goes here'; nl;
> << 'Line 2 goes here'; nl.
> better than:
> nextPutAll: 'Line 1 goes here'; newLine;
> nextPutAll: 'Line 2 goes here'; newLine.
> Although this is still subjective.
> > 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
> >> created on a certain proprietary platforms ;-) may use an encoding that
> >> not make it a platform property. Pharo should be liberal in accepting
> >> 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.
> >> 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
> >> 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
> >> Regards .. Subbu
French National Center for Scientific Research - *http://www.cnrs.fr*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13