Consider using LF instead of CR for STON-based meta data in package properties about tonel-vast

[eMaringolo]

I thing that this is an issue of STON or STON in VA in particular. STONWriter provides a way to change the newLine (and I used that to fix this issue).

In my opinion using the host OS EOL is the sensible default.

[dalehenrich]

Perhaps this is a duplicate of issue #3?

[dalehenrich]

It's not just vim where this is a problem

[eMaringolo]

@dalehenrich by the Tonel Writer uses system's default EOL defined by a Kernel package shared pool (CldtConstants::LineDelimiter).

Here there are a few options, the one taken in #3, where you can customize the EOL for the writer, or use git EOL conversion by means of a .gitattributes rule or o a global git setting.

[martinmcclure]

The forthcoming Tonel draft spec specifies that all files should use the native line ending of the local platform (CRLF for Windows, LF for Unix).

[dalehenrich]

If either CRLF or LF are allowed, then it seems that projects that use Tonel should setup a .gitattributes file with the appropriate settings to ensure that the CRLF and LF are automatically converted per platform ... is that something that could/should be included in the Tonel spec?

@martinmcclure, it is then correct to say that CR is not a legal line delimiter for Tonel files? Regardless of the setting of (CldtConstants::LineDelimiter) Tonel files should use either CRLF or LF ...

[martinmcclure]

.gitattributes is beyond the scope of the Tonel spec, since the spec does not require the use of Git. But when using Git, I would recommend the appropriate .gitattributes file to make sure that Git does end-of-line normalization for all Tonel files.

In Tonel, the only line delimiter that is legal for a Tonel Writer to write is that of the native OS platform on which the file appears. I don't know of any modern OSes that use only CR as a line delimiter. If there were any, CR would be legal there, and only there. Tonel Readers must accept either CRLF or LF.

[dalehenrich]

Regarding .gitattributes ... makes sense ... my only complaint here is readability and using the native platform's line ending would satisfy my readability complaint ... vim would see files with LF and that's the ticket ... Since Rowan uses some STON files outside the context of Tonel files, I would want the same line ending rules to apply to Rowan STON files ...

[eMaringolo]

@martinmcclure @dalehenrich : The TonelWriter is configurable as per the commit for #3, and the user has the option to normalize the EOL by means of .gitattributes.
And as you say, the EOL is commonly the one of the host OS, which in Windows is CRLF. So Rowan should expect some STON files to be written using that line delimiter too.

[dalehenrich]

@eMaringolo ...

the source of my complaint about the use of CR as the EOL character used in the STON that is the VALUE of the vaSubApplications key in the package.st file ... the EOL in the rest of the package.st file is using LF ...

the STON string used in the vaSubApplications should also conform to the host OS EOL ... and in this particular case it does not ...

On closer inspection it looks like the value of vaSubApplications is a string that is using CR as the line delimiter and I'm asking that when you generate this string (presumably independent of the TonelWriter implementation) that you take care to honor the TonelWriter line delemiter settings ...

[eMaringolo]

@dalehenrich I fixed it now, the STONWriter uses CR by default, maybe it is a bug in the STONWriter of VA? cc: @marianopeck

[dalehenrich]

@eMaringolo shouldn't that be that the STONWriter uses LF by default?

I think that the Pharo implementation of STONWriter probably did use (and may still use) CR when pretty printing, but in GemStone I've change the STONWriter pretty printer to use LF instead, otherwise STON files are unreadable (by humans) on Linux ... and of course the point of pretty printing a STON file is to make it human readable:)

[marianopeck]

Hi @dalehenrich @eMaringolo
Yes, in VAST I respected the same semantics as in Pharo, that is, use CR. I can still see this on a Pharo 8 in STONWriter >> initialize.
But..I really don't know why it makes sense to be CR. To me it looks much better either CRLF (Windows) or LF, but why CR???

I am not sure either that LF should be the default in VAST as most customers are on Windows. If we use LF then it will be unreadable by humans on Windows. So CRLF would be better here. Obviously, both scenarios could be fixed by using a proper text editor..

One final option is what we did with Tonel, which is to use, by default, the line delimiter of the current platform. So..if you are on Windows, default is CRLF and if you are on Linux it is LF.

Thoughts?

[dalehenrich]

I think that the platform EOL is the right answer, for all the same reasons that Tonel uses the platform EOL ... Pharo uses CR all over the place and all of the Pharo text editors work equally fine with CR/CRLF/LF ... but that is only true for Pharo as the rest of the world gags on CR:) ... CR was the default EOL for the original Squeak and unlike the _ for assignment has not been as quickly changed ...

[marianopeck]

OK guys, thanks for the feedback. I opened case "65559: Change STONWriter default lineDelimiter from CR to local platform default". Will be included in next release of VAST.