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 line characters I use \n. Searching for \r returns nothing. But when I replace the characters I have to use \r's. \n's give me ^@
Can anyone explain what's going on here?
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.)
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).
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.
vim does some messing around with carriage returns (\r) and newlines (\n). For instance, if you're in Unix and vi shows you lines ending in '^M' because they're Windows text files, an easy way to get rid of them is to enter the command
:%s/^V^M/^V^M/g
It doesn't look like it should do anything, but it does.
Lookup up:
:set fileformat=unix
:set fileformat=dos
This can be used on either platform to switch to the other encoding.
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.
:%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
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.