Order of carriage return and new line feed

Question

Is it important to have the correct order of carriage return then new line feed? For text editors does it matter in what order they appear?

For example instead of

\r\n

this

\n\r

Seems like Jeff has allready writen up a very nice Blog Post on the subject.

Answer 1

The traditional order, when both control characters are used, is Carriage Return, then Line Feed.

The reason for this goes back to the old ASR-33 Teletype.

When a Carriage Return is issued to an ASR-33, the print head, if it is near the right margin, takes over a tenth of a second to return to the left margin, plus there is a bit of "bounce" when the left margin is hit.

If the order were Line Feed, then Carriage Return, the first printed character might occur a tenth of a second after the Carriage Return, and thus might end up printing (as a smear) halfway across the page. But if Line Feed comes after Carriage Return then the time taken by the Line Feed provides extra time for the print head to complete its trip.

Some systems (I'm thinking the old Xerox Sigma 7 OS, e.g.) do Line Feed then Carriage Return, but they inject, e.g., NULL characters into the data stream to allow the print head to do it's thing.

And, of course, when you get to faster devices (some early 30 CPS teleprinters, e.g.), the problem gets worse and a more complex strategy is required.

(There is also the point that, for user input, the Carriage Return is provided by the user pressing the Return key, while the Line Feed must be provided by the computer. For this reason it was often the "style" to have normal print lines begin with Line Feed and end with Carriage Return. A prompt for user input, then, consisted only of a Line Feed, while the user input ended with the Carriage Return. This scheme worked well when used consistently, but of course that didn't always happen.)

Answer 2

(Sorry for the bump, but this is the main result for search results regarding this issue)

In Notepad++ it does matter. When you start with a linefeed \n and then carriage return \r, your linefeed will end up on the next line. So the order should be: CR LF

Answer 3

As just a follow up on the Carriage Return, then Line Feed research pot.

With NotePad it detects when a end-of-line when it finds the character CR+LF. This is the general format used by CP/M, MS-DOS, and Win32, Source

Unix detects a end-of-line when it finds a LF.
Apple detects a end-of-line when it finds a CR.

From a Uni-Code perspective there is a control character called NEXT LINE (NEL) just to make the situation even more complex.

With C programming language, why does it write out carriage return + line feed when you give it a line feed character? for example

printf("hello World\n").

C programming language and Unix operating system redefined line feed character as newline character with the intention that the stdio library will convert the newline character to whatever it takes to actually go to the beginning of the next line for that platform e.g., carriage return + line feed for Win32.

So when you write the new line character(That is really LF character) in either C/C++ and on either Windows or Linux the studio library will determine the output format that will need to be outputted for that end of line for that platform.

This is evident with creating a binary file or a text file in a C program. If you specify that you're writing a Binary file the studio library will leave the output format unchanged for that platform. So when writing the data to file and it comes across the newline character it will not insert the platform dependent characters for a new line.

Though coming to the conclusion after all this.

Even if you do follow the Win32 rules for Carriage Return + Line Feed to for example writing the following into a file as pure binary file.

MyText \n MyText \n MyText

And you assume it will render like this in your text editor.

MyText 
      MyText 
            MyText

Most editors instead will render it like this.

MyText 
MyText 
MyText

The confusion is mostly because of the C standard that use \n new line character for two different meanings. First, as a new line indicator for the STIO library to convert to the operating system new line format (CR+LF on win32, LF on Linux, and CR for Apple). Secondly as the just hex value line feed.

---

Well after 10 revisions and trying out different approaches on Win3.1,95,98,XP I have come to the conclusion I couldn't find an application that used CR and LF independently and can use a combination of them in the same document. Most text editors will show a square when it hits a single CR or LF. Most smarter text editors will change the file format depending if they find a CR+LF/LF/CR for the appropriate platform.

Most if not all editors are only concerned about rendering a new line to the user and will switch between the different file formats. So if your writer a lexer and string tokenizer any time soon and worried about when to detect a new line. Its best for the lower levels to detect the file format (CR+LF Win32, LF Linux, CR Apple) to increment the line number. Or use the ReadLine functionality that will take this into account.

It is puzzling to say the least, that why Carriage Return + Line Feed was adopted by IBM and Win32 as the standard for instructing the text editor to render a new line. When in fact its redundancy. I could not find a single application that rendered or used Carriage Return + Line Feed independently for the actual name it suggests it does.

So if your a University student writing the new text editor to amaze the world. Automatically detect the file format, and don't worry about the actual technical meaning given to CR+LF.

Answer 4

There are numerous newline converters out there.

E.g. this one. They do most of the work for you.

Answer 5

There are three common linefeed formats:

• \r\n for the DOS\Windows world
• \r for the pre-OSX Mac world
• \n for the Unix and Unix-like world

\n\r is not a standard anywhere that I'm aware of and will likely result in your editor thinking that it has a Unix-format text file, and then it'll display the weird \r character as text.

Historically, \r translates to carriage return (CR, ASCII code 13) which refers to old school typewriter, where you would push the carriage back to the left to return the cursor back to the start of the line. \n translates to line feed (LF, ASCII code 10) which moves the character down the page one character. Although potentially interesting, it generally doesn't matter — just use the appropriate linefeed format for your current platform.