4 ms·

It has downsides if you're actually implementing software, but \r\n is the semantically correct way to represent a newline, because \r is Carriage Return (x=0)

It has downsides if you're actually implementing software, but \r\n is the semantically correct way to represent a newline, because \r is Carriage Return (x=0) and \n is Line Feed (y++). In many scenarios \r is a useful primitive to have by itself, but if you want to support unix-style line endings you can't implement it, and you can't implement \n as a line feed - it has to be a newline. So in practice some expressiveness from the original character set was thrown out to save one byte per newline.

pdonis 9y ago
> \r\n is the semantically correct way to represent a newline, because \r is Carriage Return (x=0) and \n is Line Feed (y++) You left out a key qualifier: CR/LF is the semantically correct way to represent a newline on a physical device that has a physical carriage that has to move back to x=0 and advance one line in the y direction in order to start a new line. What devices connected to any computer today have that property? Answer: none. In fact, even on computers that have such devices connected, the semantic meaning of "newline" in any file the user actually edits is most likely not to actually cause a CR/LF on the device. Word processing programs for decades now have separated the in-memory and on-disk file data from the data that actually gets sent to a printer. So the file you are editing might not even have any hard "newlines" in it at all, except at paragraph breaks--and that's assuming the file format uses "newline" to mark paragraph breaks, instead of something else.
- ygra 9y ago
  I find it funny that CRLF as a vestige of devices long gone is ridiculed, yet the same people don't bat an eye at emulating an in-band sort-of API for controlling cursor movement and display characteristics for similar devices of the past. Heck, *roff and man continue to format text by using overstriking to create underlined and bold text and rely on the terminal emulator to understand that this happened to create a particular effect on physical printers and emulate the result. Neither world is clean, pure, and free of weirdness that's only properly understood when looking decades in the past.
  - JdeBP 9y ago
    Actually, the GNU tools (in particular grotty) advanced forward to 1976, and are capable of ECMA-48 control sequences that render actual italics and boldface like the source markup describes. It is just that the people who make operating systems have gone out of their way to disable this. * http://jdebp.eu./Softwares/nosh/italics-in-manuals.html http://jdebp.eu./Softwares/nosh/italics-in-manuals.html
- zamalek 9y ago
  > Answer: none. Dot matrix printers are surprisingly common as they are still cheaper to run than the alternatives. That's at least one.
- pedasmith 9y ago
  Indeed, I'm looking at my copy of "The C Program Language", second edition (ANSI C). Page 241: A text stream is a sequence of lines; each line has zero or more characters and is terminated by a \n. [\n was defined earlier as ASCII 10 and designated either as NL or LF.] An environment may need to convert a text stream to or from some other representation (such as mapping '\n' to a carriage return and linefeed)"

pdonis 9y ago

> \r\n is the semantically correct way to represent a newline, because \r is Carriage Return (x=0) and \n is Line Feed (y++) You left out a key qualifier: CR/LF is the semantically correct way to represent a newline on a physical device that has a physical carriage that has to move back to x=0 and advance one line in the y direction in order to start a new line. What devices connected to any computer today have that property? Answer: none. In fact, even on computers that have such devices connected, the semantic meaning of "newline" in any file the user actually edits is most likely not to actually cause a CR/LF on the device. Word processing programs for decades now have separated the in-memory and on-disk file data from the data that actually gets sent to a printer. So the file you are editing might not even have any hard "newlines" in it at all, except at paragraph breaks--and that's assuming the file format uses "newline" to mark paragraph breaks, instead of something else.

ygra 9y ago
I find it funny that CRLF as a vestige of devices long gone is ridiculed, yet the same people don't bat an eye at emulating an in-band sort-of API for controlling cursor movement and display characteristics for similar devices of the past. Heck, *roff and man continue to format text by using overstriking to create underlined and bold text and rely on the terminal emulator to understand that this happened to create a particular effect on physical printers and emulate the result. Neither world is clean, pure, and free of weirdness that's only properly understood when looking decades in the past.
- JdeBP 9y ago
  Actually, the GNU tools (in particular grotty) advanced forward to 1976, and are capable of ECMA-48 control sequences that render actual italics and boldface like the source markup describes. It is just that the people who make operating systems have gone out of their way to disable this. * http://jdebp.eu./Softwares/nosh/italics-in-manuals.html http://jdebp.eu./Softwares/nosh/italics-in-manuals.html
zamalek 9y ago
> Answer: none. Dot matrix printers are surprisingly common as they are still cheaper to run than the alternatives. That's at least one.
pedasmith 9y ago
Indeed, I'm looking at my copy of "The C Program Language", second edition (ANSI C). Page 241: A text stream is a sequence of lines; each line has zero or more characters and is terminated by a \n. [\n was defined earlier as ASCII 10 and designated either as NL or LF.] An environment may need to convert a text stream to or from some other representation (such as mapping '\n' to a carriage return and linefeed)"