I'm using Emacs on Windows. Everything was fine just a few minutes ago, but for some odd reason, when I open a certain file, I get ^M characters after every line. As far as I know/remember, I didn't do anything to the file except refile a a couple org-mode items (and they didn't contain any strange characters like smart quotes or anything either)... and yet when I closed then reopened the file a few seconds later, these characters appeared. It only happens for that file; other buffers seem to be okay.

Based on my research, ^M seems to be the end of line character for Windows.

Following this, executing M-x revert-buffer-with-coding-system utf-8-dos seems to fix the problem until I open the file again, at which point the ^Ms return.

The only encoding-related thing I have in my init.el file is

(set-language-environment "UTF-8")
(set-default-coding-systems 'utf-8)

which hasn't changed since I set them a couple months ago.

Does anyone have any idea what happened?

Update: One thing I noticed (after disabling my modeline theme) is that the file in question seems to always want to revert to (Unix) Unix-style LF line endings, when all my other (working) files are set to \ DOS-style CRLF line endings. I have some characters like é and あ in my file, but they hadn't caused problems before...

Here's a comparison of the modeline indicators:

  • (Working) File with no ^M, no foreign characters: -\ undecided-dos, DOS-style CRLF
  • (Not working) File with ^M, with foreign characters: =(Unix) no-conversion, Unix-style LF
  • (Working) File with no ^M, with foreign characters: U\ utf-8-dos, CRLF

The "not working" file always seems to want to open with (Unix) and no-conversion...

Update 2: I seem to have temporarily been able to solve this by forcing the buffer to read the file as utf-8-dos by including # -*- coding: utf-8-dos -*- at the top.

I will leave this question open, however, as I still would like to know what caused this, and why emacs suddenly decided it wanted to encode the file as no-conversion even though it had been handling foreign characters just fine earlier in the day...

  • does the file start with # -*- coding: utf-8-unix -*-, or, near the bottom? Or, describe-variable on require-final-newline and mode-require-final-newline. Emacs might added a newline while it still think the file is utf-8-unix.
    – Xah Lee
    Oct 16, 2016 at 18:45
  • No, that line doesn't appear anywhere in the file. require-final-newline and mode-require-final-newline are both set to t for all the files (working and not working).
    – wiuah
    Oct 16, 2016 at 18:52
  • Can you reproduce this if you open the file in emacs -q? in emacs -Q? If not then you need to post your init file. Can you share a file without any private data that reproduces the problem? Do you have the same issue if with a copy of that file? with a copy with a different name and extension? Oct 17, 2016 at 19:14

1 Answer 1


Are you sure every line ends with a ^M? If just a single one doesn't then you will get the symptoms you describe.

You can search for such lines with isearch-forward-regexp, e.g.

escape ctrl-s [ ^ ctrl-q ctrl-m ] $

The [^^m] matches any character that is not ctrl-m, and the dollar matches the end of line.

When you find a line which is missing a ctrl-m, you can add one with

ctrl-e ctrl-q ctrl-m

Once you have changed all the lines you can save the file and reload it, and hopefully the issue will have gone away.

  • Fair enough - searching for anything that isn't ^M points me to the very last line of the file.
    – wiuah
    Oct 17, 2016 at 2:18
  • So a file where every line ends with ^m^j then it is taken to use ^m^j as the the end of line indicator (unless you override it). If only most do, then ^j is the end of line and the ^m is just another character like e or t.
    – icarus
    Oct 17, 2016 at 6:18
  • If that's the case, then it's a matter of why emacs is inserting a ^j at the end of the file (could this have to do with the require-final-newline setting?), right? If I delete the ^Ms at the end of the file, save, and reopen, however, the problem still remains.
    – wiuah
    Oct 17, 2016 at 16:25
  • If the file is opened with the correct encoding then the require-final-newline setting should make it add ^m^j. My suggestion is to add ^m to files where they are missing, not to delete existing ^m characters.
    – icarus
    Oct 18, 2016 at 0:10

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