1

When editing a dos-format file from a codebase which is mainly used with Visual Studio in a Windows environment on my local Ubuntu machine with VIM, I get to see the ^M character instead of a newline.

According to the VIM documentation, this represents the carriage return character.

Further complicating the problem is that this only occurs in certain places in the file, so the newlines don't seem to have a consistent format.

By default, VIM recognizes the file as dos file-format, which I see by executing :set ff?.

My goal is to edit the file without breaking its platform conformity; I don't want to persistently convert the file, only because I'm editing in VIM. Hence, the existing answer doesn't satisfy my problem. This answer, doesn't either.

Given this requirement, can I get VIM to just display all ^M's as newlines via some syntax highlighting setting?

Note that ^M isn't composed out of plain characters. I you'd insert them manually in VIM, you'd have to insert Cntr-V before inserting each character.

easytarget
  • 945
  • 2
  • 13
  • 35
  • The second answer `:e ++ff=dos` is actually quite good — `vim` converts the file from dos format on reading and will convert it back to dos on writing. I'm sure this is exactly what you want. – phd Jan 22 '18 at 12:07
  • @phd It doesn't seem to have any effect on the file. That is, when I execute `:e ++ff=dos` while I have the file loaded in a buffer. – easytarget Jan 22 '18 at 12:38

1 Answers1

0

this only occurs in certain places in the file

There's your problem. If CR-LF were used consistently for all line endings, Vim would (with dos in 'fileformats') correctly detect Windows-style line endings, and handle them transparently (i.e. without showing ^M).

As it is not, Vim detects the file as unix, and displays the parts with Windows line endings with a trailing ^M. You could use the conceal feature to hide them:

:syntax match hideControlM "\r$" conceal
:set conceallevel=2 concealcursor=nv

But if you want to maintain the original structure as much as possible, you need to be able to view them, and add them manually (via <C-V><C-M>) if you add lines inside those Windows-style areas.

Many people would argue that such inconsistent line-ending style is a bug and should be converted to an agreed-upon, consistent line-ending style. Most version control systems (I hope you use one) have automatic conversion features that make it easy to achieve interoperability with both Windows and Unix users.

Ingo Karkat
  • 167,457
  • 16
  • 250
  • 324
  • How could I possibly not use version control? :) I didn't know that most have automatic conversion features though. Thanks for the tip. – easytarget Jan 24 '18 at 17:25
  • I'm probably going to settle on fixing the line inconsistencies by replacing the `^M` characters with newlines. – easytarget Jan 24 '18 at 17:29
  • *You could use the conceal feature to hide them:*. *Just* concealing them doesn't solve the problem; they are supposed to be interpreted as legitimate newlines. If not, that a distorted view results in some places. – easytarget Jan 24 '18 at 17:31
  • If you replace `^M` with a newline, don't you have two subsequent ones (with a Unix view of newline = LF)?! For Windows, `^M` alone isn't a newline, it's the CR-LF combination: `^M^J`. – Ingo Karkat Jan 24 '18 at 18:08