> On 5 Aug 2017, at 11:17, Peter Uhnak <i.uh...@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 <tu...@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 <esteba...@gmail.com> wrote: >>>> >>>> >>>>> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pol...@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, teso...@gmail.com <teso...@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" <esteba...@gmail.com> wrote: >>>>> >>>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.s...@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.vr...@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." >>> >>> >> >> >
