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...

closed as too broad by Gilles Oct 17 '16 at 19:14

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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 '16 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 '16 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? – Gilles Oct 17 '16 at 19:14

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 '16 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 '16 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 '16 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 '16 at 0:10

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