Vim: \n vs. \r

Question

I haven\'t used vim in a Unix system in a while, but as I recall there was no \\r, it was always \\n.

I\'m using gVim under windows and when I search for new

Answer 1

Looks like you're asking two things. One issue is \r vs. \n which others have covered.

The other issue is \n on the right side of a substitution. If you look at :h s/\n, it says that \n in the replacement part of a substitution inserts a <NUL> / <NL>, NOT a newline.

If you do a :%s/\n/\n/ and save and open the file in a hex editor, all the ^@ characters are ASCII 0's (NUL characters). Why the Vim devs use \n on the left for end-of-line and \n on the right for NUL is beyond me. But this particular behavior has nothing to do with Windows vs. Unix.

Answer 2

Behind the scenes, Vim uses \r (carriage returns) to save End-Of-Lines (regardless of the fileformat, which only matters when the file is being read or written). Vim uses \n to represent NULs. However, you search for EOL as \n, but in the replacement, \n stands for NUL. It's explained in :h sub-replace-sepcial. Searching for \r will find carriage returns that weren't part of the fileformat's EOL. There is a long explanation at :h file-formats.

Answer 3

Under unix, inside vim, ^V + <enter> gives me a ^M which is the \r character.

Also, you can't find \r inside vim unless you tell it to edit the file in binary mode, that is, not using the default automatic mode where it autodetects the line ending. (it should print [dos] in the status.)

Answer 4

In Windows, if you open up a file in text mode, \n is interpreted as both the newline and linefeed characters. This normally isn't the case the *nix systems.

Answer 5

I think the problem might lie in the way that Windows and Unix do newlines. The format for Unix is \n (line feed) but for Windows it is \r\n (carriage return, line feed).

Answer 6

:%s/^V^M/^V^M/g

Similarly, the following does the same thing (I think), and is easier to type out.

:%s/\r/\r/g