Hi all, 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 conversion also. 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. Guille On Sat, Aug 5, 2017 at 8:03 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Stef,
On 5 August 2017 at 18:14, Stephane Ducasse <stepharo.self@gmail.com> wrote:
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:
stream << 'Line 1 goes here'; nl; << 'Line 2 goes here'; nl.
better than:
stream nextPutAll: 'Line 1 goes here'; newLine; nextPutAll: 'Line 2 goes here'; newLine.
Although this is still subjective.
Cheers, Alistair
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.ml@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
-- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13