Hi,

just to (hopefully) clarify my intention, maybe pseudocode would describe my thoughts better.

Stream>>beForWindows
�� �� �� �� "Use consistenly Windows line endings (CRLF) in the stream"
�� �� �� �� self convertLineEndings: true
�� �� �� �� lineEnding := String crlf

Stream>>convertLineEndings: aBoolean
�� �� �� �� "automatically convert line endings to the predefined one"
�� �� �� �� convertLineEndings := aBoolean

Stream>>nl
�� �� �� �� self nextPutAll: lineEnding

Stream>>cr
�� �� �� �� convertLineEndings ifTrue: [
�� �� �� �� �� �� �� �� self deprected: 'Using #cr/#lf for generic newlines is deprected, use #nl instead".
�� �� �� �� �� �� �� �� self nl.
�� �� �� �� ] ifFalse: [
�� �� �� �� �� �� �� �� self nextPutAll: String cr.
�� �� �� �� ]


So when "convertLineEndings = true", then using anything else than #nl would warn the user that they should use #nl instead (as they explicitly requested to have the line endings consistend).

And when "convertLineEndings = false", it would behave pretty much the same way as now, #cr would write #cr, etc.


With such approach imho

* output of existing code wouldn't be broken
* when switching to new scheme (#nl) the programmer would be warned where the missed a change
* it will be easier to keep the newlines consistent

Peter

On Sat, Aug 05, 2017 at 11:30:58AM +0200, Esteban Lorenzano wrote:
>

> > On 5 Aug 2017, at 11:17, Peter Uhnak <i.uhnak@gmail.com> wrote:
> >
> >> I think there is a consensus we need to keep #cr and #lf as intended
> >
> > Is there?
> >
> > My argument was that there's no (obvious) reason to combine different line endings in the same document. Therefore if you were to use #cr, #lf, #crlf, you would actually mean that you just want to enter newline.
>
> no, sometimes you want to enforce a specific line ending. You will not mix, but you will not use the one from platform. Also, sometimes you actually can use #cr and #lf different as their immediate, common use (I���ve seen some weird exporting formats).
>
> >
> > Similar problem arises when you would write a multiline string:
> >
> > stream nextPutAll: 'first line with enter
> > second line'.
> >
> > Stored in method this will most likely contain Pharo's internal representation (#cr), even though you just want a new line, and not specifically #cr. (I've lost count how many times tests on CI failed because of this.)
> >
> > Considering the above, my opinion is:
> >
> > 1) by default #cr, #lf, #crLf, #nl (#newLine) will write whatever is globally configured for the stream (#beFor*)
>
> No, I strongly disagree.
> #cr and #lf are ascii characters and should not be redefined.
>
> > 2) if one wanted to combine different line endings in the same stream, there should be an option to disable autoconversion. (Stream>>noNewLineAutoconversion)
> >
> > If (1) is much more common than (2), then imho autoconversion should cause no issues.
> > If (1) is NOT that much more common than (2), then autoconversion wouldn't be beneficial.
> >
> > Autoconversion could also make transition easier because existing code will suddenly work as intended here without breaking anything (hopefully).
>
> Sorry, I do not see what this approach solves than the other one does not (and as I see, this one is a lot more complicated and prone to confusion).
>
> cheers,
> Esteban
>
> >
> > Peter
> >
> >
> > On Sat, Aug 05, 2017 at 10:49:02AM +0200, Esteban Lorenzano wrote:
> >> I think there is a consensus we need to keep #cr and #lf as intended, yet to add some kind of #newLine (which btw is different to EOL :P) vocabulary, isn���t?
> >>
> >> In this, I favour Peter approach for define line ending convention (the way #newLine will work)��� and of course by default it should use the one from the current platform.
> >>
> >> anything agains this approach?
> >>
> >> Esteban
> >>
> >>
> >>> On 4 Aug 2017, at 23:48, Tudor Girba <tudor@tudorgirba.com> wrote:
> >>>
> >>> +1.
> >>>
> >>> We need a basic representation of those characters. Logical ones should be derived from the simple ones.
> >>>
> >>> Doru
> >>>
> >>>
> >>>> On Aug 4, 2017, at 3:44 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
> >>>>
> >>>>
> >>>>> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@gmail.com> wrote:
> >>>>>
> >>>>> I agree with Pablo, #cr and #lf should not be clever and just be names for the carriage return and linefeed characters/codepoints.
> >>>>
> >>>> +1
> >>>>
> >>>>>
> >>>>> Making #newLine's behavior dependent on the current platform disturbs me, though. I'd rather have:
> >>>>>
> >>>>> Stream >> newLineFor: platform
> >>>>>�� ��self nextPutAll: platform lineEnding
> >>>>>
> >>>>> Stream >> newLineForCurrentPlatform
> >>>>>�� ��self newLineFor: OSPlatform current
> >>>>>
> >>>>> Stream >> newLineForWindows "convenience for the most common platforms
> >>>>> Stream >> newLineForUnix
> >>>>> Stream >> newLineForHistoricReasons
> >>>>>
> >>>>> Stream >> newLine
> >>>>>�� ��"delegates to one of the above, I'd argue for unix for convenience, but windows is the technically correct combination of cr + lf, and cr only is the historic one"
> >>>>>
> >>>>>
> >>>>> On 4 August 2017 at 14:25, tesonep@gmail.com <tesonep@gmail.com> wrote:
> >>>>> To me it is clear that cr and lf should be in streams. But they should put the 'cr' or 'lf' character only. And of course the platform independent newline should be also.
> >>>>>
> >>>>> The first (cr, lf) should be used by the code wanting to have absolute control of what is in the stream. The later (newline) when you just want a new line.
> >>>>>
> >>>>> The two have completely different behaviour, ones are really low level, the other is higher level.
> >>>>>
> >>>>> On 4 Aug 2017 14:20, "Esteban Lorenzano" <estebanlm@gmail.com> wrote:
> >>>>>
> >>>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@gmail.com> wrote:
> >>>>>>
> >>>>>> Well. This is not implemented like that in Pharo.
> >>>>>>
> >>>>>> cr is bad because it does not mean that it is independent of the platform.
> >>>>>> So cr can be redefined as newLine and keep but not used inside the system.
> >>>>>
> >>>>> sometimes you actually want to write a cr (or a lf). So it needs to remain in the system, of course.
> >>>>> now, including #newLine can be cool (most of the times you want the ���platform compatible��� new line). Also I would consider including #nl, abbreviated��� just for convenience :P
> >>>>>
> >>>>> Esteban
> >>>>>
> >>>>>>
> >>>>>> Stef
> >>>>>>
> >>>>>> On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
> >>>>>>> On Fri, 2017-08-04 at 12:03 +0200, Stephane Ducasse wrote:
> >>>>>>>> Hi guys
> >>>>>>>>
> >>>>>>>> While writing pillar code, I ended up using "stream cr" and it
> >>>>>>>> worries
> >>>>>>>> me to still expand usage
> >>>>>>>> of a pattern I would like to remove.
> >>>>>>>>
> >>>>>>>> Let us imagine that we would like to prepare the migration from cr.
> >>>>>>>> I was thinking that we could replace cr invocation by newLine so that
> >>>>>>>> after newLine
> >>>>>>>> could be redefined as
> >>>>>>>>
> >>>>>>>> Stream >> newLine
> >>>>>>>>�� �� ��self nextPutAll: OSPlatform current lineEnding
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> what do you think about this approach?
> >>>>>>>
> >>>>>>> Why not? But please keep #cr.
> >>>>>>>
> >>>>>>> Section 5.9.4.1 of ANSI reads:
> >>>>>>>
> >>>>>>> Message: cr
> >>>>>>>
> >>>>>>> Synopsis
> >>>>>>> Writes an end-of-line sequence to the receiver.
> >>>>>>>
> >>>>>>> Definition: <puttableStream>
> >>>>>>> A sequence of character objects that constitute the implementation-
> >>>>>>> defined end-of-line sequence is added to the receiver in the same
> >>>>>>> manner as if the message�� #nextPutAll: was sent to the receiver with
> >>>>>>> an argument string whose elements are the sequence of characters.
> >>>>>>>
> >>>>>>> Return Value
> >>>>>>> UNSPECIFIED
> >>>>>>> Errors
> >>>>>>> It is erroneous if any element of the end-of-line sequence is an
> >>>>>>> object that does not conform to the receiver's sequence value type .
> >>>>>>>
> >>>>>>> my 2c,
> >>>>>>>
> >>>>>>> Jan
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Stef
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Damien Pollet
> >>>>> type less, do more [ | ] http://people.untyped.org/damien.pollet
> >>>>
> >>>
> >>> --
> >>> www.tudorgirba.com
> >>> www.feenk.com
> >>>
> >>> "Presenting is storytelling."
> >>>
> >>>
> >>
> >>
> >
>
>