CRLF as official line ending

[Allen Smith]

Following up with the previous topic, I would like to propose that DOS-style CRLF line-endings be officially specified as the standard output format for LDraw editors.

While I personally believe that DOS line endings are the most ridiculous line endings known to man, they're the de facto standard in LDraw and I don't think that should change. I agree with the idea to put them in the specification as a help to any future software author.

As to the input format, I believe software must support DOS line endings, and should support all line endings.

Thoughts?

Allen

[Chris Dee]

I agree - in fact it was a surprise to me to learn that it is not in the official specification.

[To those of us whose first experience of computers was a teletype terminal - carriage-return, line-feed is entirely logical. As is restricting line length to the 80 columns of an IBM punch-card :-) ]

[Travis Cobbs]

It works for me. As for guidance for reading files, I think we should specify exactly what should be supported, instead of just "all". I know most LDraw software supports CRLF as well as LF, but I suspect that other line endings (Mac prior to OS X was CR, for example) aren't nearly so widely supported.

My personal vote would be to say that any program reading an LDraw file should be capable of reading files with lines ending with either CRLF or LF. However, I'm open to also suggesting support for CR-terminated files if others feel it's useful.

[Willy Tschager]

Fine. As I understand it we would move this:

http://www.ldraw.org/Article512.html#termination

to

the LDraw.org File Format Version 1.0.1 page.

Correct?

w.

[Travis Cobbs]

Yes, but I think something like the following should be added onto the end of the paragraph:

All LDraw-compliant programs should also be capable of reading files with the standard Unix line termination of <LF> (line feed).

[Allen Smith]

All LDraw-compliant programs should also be capable of reading files with the standard Unix line termination of <LF> (line feed).

I am skeptical of trying to make this mandatory. I think it is a courteous thing to implement and everybody ought to, but I don't see why it should be required.

I also don't see why the file should be required to end in a newline.

Allen

[Chris Dee]

I also don't see why the file should be required to end in a newline.

IIRC, one of the original programs (LDraw or LEdit) ignored the last line if it was not terminated with <CR><LF>. That's why there was a convention (now obsolete) that the last line should be an empty comment. If the <CR><LF> was omitted from the comment it didn't matter.

[Roland Melkert]

I'm having mixed feelings about this. I agree on the dos style output by default, but by stating software must be able to read other formats as well you contradicting the standard you just set.

edit: I'm not against (forcing) support for single CR and or LF.

[Travis Cobbs]

Technically, in spec-speak, the "should" in my text means that it's not mandatory (which was my intention). However, I can acknowledge that most people won't have memorized RFC 2119. Based on text in the RFC, the following would be more explicitly clear to those people (i.e., virtually everyone):

It is recommended that all LDraw-compliant programs also be capable of reading files with the standard Unix line termination of <LF> (line feed).

(In case it's not obvious, I'm trying here to be sarcastic regarding my own original text, and not towards people who wouldn't have understood it.)

[Willy Tschager]

More comments on this?

w.

[Travis Cobbs]

I also don't see why the file should be required to end in a newline.

Your statement here is a lot less strong than the one in your NO vote. If you had said here that BrickSmith has always omitted that final newline, I think it would have led to some discussion.

To be honest, I don't have a strong opinion of the final newline. Somewhat ironically, though, text files with no EOL at the end were historically considered to be bad in Unix. In fact, vi gives a notice when such a file is loaded, and is itself incapable of creating such files (or if it is possible, you have to jump through hoops). And text files in DOS often skipped the final newline.

I haven't yet responded to Willy's Call for Votes because of the reason you gave in your NO vote. I'd like to see what others think here.

[Allen Smith]

Your statement here is a lot less strong than the one in your NO vote. If you had said here that BrickSmith has always omitted that final newline, I think it would have led to some discussion.

Yeah, that's entirely my fault and I apologize. I don't think I realized what I had implemented when I wrote the post you quoted (I wrote that code 7 years ago and haven't touched it since). Once I looked it up and realized what I'd done, I had meant to bring it up here. But I hadn't gotten around to it yet.

If everybody else voted yes I wouldn't be angry and I'll update my software. But I do disagree with the final newline requirement. I think it's unnecessarily restrictive, and I think software authors need to accept files with or without a final newline in a user-editable text-based format. I also have somewhat unwittingly given myself a vested interest in voting against it, so vote against it I did. (Sorry! Nothing personal!)

Allen