I have been using Emacs on Windows for decades now and it essentially always worked fine except for minor annoyances. However, I recently had to buy a new machine with Windows 10 (the last Windows I used Emacs on was Win7) and now I'm in the strange situation that Emacs can't write to ~/.emacs anymore. Whenever I try to do that, I get a message about wrong file permissions. If I then close and restart Emacs, it can't even read the file anymore, so I have to fix the permissions (which I usually do with Cygwin). To be clear: The file permissions are fine before Emacs tries to write to ~/.emacs, but then Emacs itself somehow messes up and as a result it can't read or write the file anymore.

I have "fixed" the problem for now by renaming the file to ~/_emacs, but I'd like to know what the reason for this behavior is. (And in the long run I'd like to get rid of the warning message that the underline is deprecated...)

Emacs version is: GNU Emacs (x86_64-w64-mingw32) of 2016-05-26

(I'm also using Emacs via a pretty old version of gnuserv in case that matters.)

  • 1
    This does not answer your question, but for the time being, you could copy ~/_emacs to ~/.emacs.d/init.el; it could help getting rid of those warnings while fixing the issue. – Arash Esbati Jun 24 '16 at 14:06
  • NTFS is extremely weird about characters in directory and file names. – wasamasa Jun 24 '16 at 18:23
  • @ArashEsbati: Thanks, that worked. I didn't think of trying that. I probably expected the same problems because there's also a leading dot there, but it seems to be OK. – Frunobulax Jun 25 '16 at 8:37
  • @wasamasa: Yes, but I've had ~/.emacs living on NTFS file systems for years without problems. The only difference was that none of these machines had Win10 running. – Frunobulax Jun 25 '16 at 8:38
  • "old version of gnuserv" - is that what's described here? Seems to be obsolete since Emacs 22 (which was released in 2007). – npostavs Feb 10 '18 at 4:28

I've been running Emacs 22 and 24.4 on Windows 10 for years, without problems writing the init file. The doc says that Emacs searches for ~/.emacs, ~/.emacs.el, and ~/.emacs.d/init.el, in that order.

On Windows, ~ (the HOME environment variable) is not defined by default, so you must define it through Control Panel, System, Environment Variables, if you want to use those locations.

Otherwise, by default, Emacs 22 and 24 will search in /Users/name/AppData/Roaming/ for .emacs.

I do know that trying to save files to Windows (all versions) from Emacs often requires using double backslashes in the pathnames that you formulate in code. I've found that double backslashes are the only trustworthy way.

So to answer your question, I can assert:

  • Windows 10 is capable of .emacs filenames, you don't require _emacs.

  • Windows 10 is capable of .emacs, in both HOME=/users/name/.emacs form, and in the AppData/Roaming/.emacs form. I don't like the AppData/Roaming location, because /users/name/AppData is a hidden directory on Windows, which makes it awkward to work with.

  • You might check to see if you have a HOME environment variable defined, and what it points to (maybe a location with bad permissions?). You might check your /users/name/AppData/Roaming/.emacs path for permissions all the way down, too. (The original post doesn't exactly specify the HOME part of the ~/ references.)

  • This might sound awful (but it has happened to me), but you might check to see that you have exactly 1 startup file, in exactly 1 location, and that your main init file code doesn't reference or reload any other .emacs files from any other places. I use three machines (win10, win10, Mac OSX, and share almost everything through Dropbox), and when installing new versions of Emacs I sometimes end up referencing old files, in old locations.

One of the handiest tips I can pass on for this particular problem is to color the background a different color in the init file, as the first line. Then if you see unexpected colors, you will know you're not picking up (or trying to write out--yes, that's happened to me too) the wrong .emacs file.

Now my policy is to have .emacs files with only 1 line in them -- and it loads the big shared init file where I look at machine types and do machine-specific setups. That might work for you too, since then your .emacs file won't change much at all, for the life of the machine. Only the big shared (ie, secondary) init file will be regularly modified, and that can be located anywhere you like.

Hopefully some of this might help. Good luck!

  • Thanks. Good to know that it's not a Win10 problem per se. $HOME is set (to a top-level directory as I've always done it for eons) and I'm sure there's only one startup file. What is a bit fishy is that Windows complains that the access rights of the home directory are in the wrong order. (Could this be because the directory was created from Cygwin?) But why is this a problem for .emacs and not for _emacs? – Frunobulax Jun 26 '16 at 19:40
  • Maybe Cygwin has an issue with dotted files under Windows, or sets the permissions funny. (To test that idea out, move the directory aside, and create a new one with mkdir, put your .emacs in the new dir, and see if that fixes it.). It's probably a fair bet that if Emacs is protesting write permissions, that is what Emacs is seeing at the time of the write. (For me, I would jump to the double slash issue, since that's the most common issue on Windows that I've seen. It manifests in strange ways.) – Kevin Jun 26 '16 at 20:59
  • I just had a very similar problem with Windows-10 and it appears that the problem stems from win-10 seeing an extension without a filename as opposed to a filename without an extension. .emacs has problems whereas neither _emacs nor .emacs.el have similar issues. So with _emacs being deprecated .emacs.el seems to be the most straightforward solution. – bielawski Dec 27 '17 at 14:28

Try setting the HOME environment variable explicitly.

Under Windows 10 my emacs wouldn't read the .emacs file in my HOME directory until I set HOME to C:\Users\James

Now it works.

Right click "This PC" on desktop, select "Properties", click "Advanced system settings", Click "Environment Variable", click "New" under the upper window, Enter "HOME" in the "Variable name" box, and enter "C:\Users\YOUR_NAME" in the "Variable value" box. Click "OK" and you're good to go.

  • As I already said (see comment from June 26, 2016), the HOME environment variable is set. – Frunobulax Feb 10 '18 at 9:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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