I am using Vim on multiple operating systems (OS X, Windows, Linux Mint) on a daily basis, and I chose to have those directory-free and/or distribution-independent settings synced across the machines through a shared Dropbox folder. Ideally, the following line in .vimrc shall do the trick:

source ~/Dropbox/Tool_Private/Vim-Spelling/general_setting.vim

However, while things are working well across my two Windows machines, I am getting the following errors from my MacBook Air:

Error detected while processing /Users/{user}/Dropbox/Tool_Private/Vim-Spelling/general_setting.vim:
line    8:
E474: Invalid argument: iskeyword+='^M
line   10:
E492: Not an editor command: ^M
line   11:
E492: Not an editor command: ^M
line   15:
E15: Invalid expression: 1^M
line   16:
E15: Invalid expression: '~/Dropbox/Tool_Private/Vim-Spelling/Views'^M
line   18:
E492: Not an editor command: ^M
line   24:
E488: Trailing characters

Does this have to do with character encoding? I have set the following lines in all my .vimrc(or _vimrc for Windows) across all my machines:

set fileencoding=utf-8
set encoding=utf-8

Yet, I shall still have those trailing ^M characters, which might have caused the error.

1 Answer 1


^M is a carriage return character. It's plain old ASCII (0x0D) and thus perfectly valid UTF-8 encoded Unicode.

Vim on windows defaults to using Windows-style line endings: CRLF (Carriage Return, Line Feed).

On a Unix-based system, including macOS (X, not classic) and Linux, Vim will default to Unix-style line endings: LF. Thus, when reading a Windows formatted vimrc, Vim on a Unix-style system is going to see an extra character at the end of every line and wonder what the heck is going on.

The good news is that Vim on Windows is able to read Unix-style line endings just fine. So rather than saving your vimrc with CRLF line endings, just use LF line endings. An easy way to convert is to open it in Vim on Windows, and run :set fileformat=unix, then save it with :w. Christian Brabandt pointed out that this can be done in fewer steps with :w ++ff=unix. You might be able to make the same change on a different OS, but I have vague recollections of ending up with CRCRLF, which doesn't make anyone happy.

As an alternative, you could use a version control system instead of Dropbox to share your vim files between computers. Git can automatically check files out with the correct line endings depending on which OS it's currently on, and I would be quite surprised if other modern VCSs lacked the same functionality. Places like Bitbucket and Github can provide free hosting. As an extra benefit, you can get great history tracking, potentially useful if you want to experiment with new settings for a while and still be able to easily roll back. As a downside, syncing is rather less automatic, at least without some extra up front effort.

  • 1
    I usually do :w ++ff=unix Commented Feb 7, 2017 at 19:44
  • @Chris, ++ff=unix solved my problem! Thank you!
    – llinfeng
    Commented Feb 8, 2017 at 1:23
  • @8bittree: I have changed the fileformat throughout, but it does not appear to help. @Chris's answer directly solves my problem. Thank you as well!
    – llinfeng
    Commented Feb 8, 2017 at 1:23
  • @llinfeng Odd. I actually ran a sample through xxd with both fileformat settings and verified that the actual bytes in the file changed. Strange that that did not work for you, even though the documentation for ++ff=unix indicates that it just sets fileformat for one command. You did do a :w after :set fileformat=unix, right?
    – 8bittree
    Commented Feb 8, 2017 at 15:21
  • @8bittree, exactly: I have put set fileformat=unix among the first few lines in my _vimrc (on Windows machine), and saved the file using :w<cr>; then, I moved to the MacBook Air and waited a while for Dropbox to sync. Then, sourcing such file failed. Should it be the case that I have placed set fileformat=unix incorrectly? I also checked that I have not sourced the mswin.vim at all.
    – llinfeng
    Commented Feb 8, 2017 at 21:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.