^M visible with
set ff? reports that the file is
dos and you are seeing
^M carriage return characters at the end of any lines, then your file already has broken, non-conforming line-endings.
e.g. if the file displays like this:
another regular line
line with an extra carriage return^M
third regular line
This means that the actual content of your file looks something like (broken into lines for clarity):
another regular line^M^J
line with an extra carriage return^M^M^J
third regular line^M^J
If this is the case, the appropriate cause of action is simply to delete the extra carriage return and to look into how the file came to have such odd line endings.
^M visible with
A more common scenario is that you have a file with mixed endings. This would result in a file where certain (dos-formatted) lines are displayed with a
^M at the end of the line. If you were seeing a file like this, however,
:set ff? would report
This scenario can be fixed by adding carriage returns to lines which do not have them. I usually do this by yanking a carriage return from one of the lines that has one, and then using a
N.B. As far as I am aware, you cannot easily perform the above fix with a
:substitute command, because the carriage return in the replacement would be interpreted as a newline and instead a linefeed will be added.
The carriage returns will still be visible after running command, but when you save and reopen, Vim will reinterpret the file as
An alternative fix is to remove all the carriage returns at the end of lines:
This leaves you with a file with
unix line endings, but it's easy to get Vim to convert these back into
dos line endings:
^M instead of newlines
It turns out that what the OP is seeing is something like this:
first line^Msecond line
This means that some of the line-endings don't contain linefeeds at all, they are just a carriage return. (This is old "Classic" MacOS style for line-endings —
Similarly to the situations described above, this is incorrect in a
dos formatted file: the file is malformed, even if Visual Studio displays it in a way that looks correct.
This can be fixed with the following confusing
Of course, the command doesn't actually replace all carriage returns with carriage returns!
In the "search" part of the command the
\r carriage return will only match the ones that are not being using in a CRLF line-ending pair. In the "replace" part, the carriage return is interpreted as a newline, splitting the lines correctly.
After making the edit, the file will now be correctly formatted with
dos endings throughout, and so will display correctly both in Vim and Visual Studio.
Viewing the actual contents with
Vim comes with a hex editor that can be used to view (or edit) the byte-level contents of the file. If you're sceptical about what I've written above, you can double-check what actual line-endings are being used with the command:
N.B. This will replace the contents of your file with a hex-dump: when you are done, press
u to undo the change and return to your file.
The regular contents are displayed on the right, the corresponding hex-codes on the left. On the right-hand side, both carriage returns and linefeeds are displayed as dots, so a unix line-ending will be shown as
. a dos line ending as
.. and a dos ending with an extra carriage return as