Can’t you follow the XDG specs and put the config files in ~/.config/atom, like any sane person in 2014 would do?
And before this even comes up, configuration in Windows also shouldn’t go into the user directory, but to
And on the Mac:
I would assume this is because it’s early days. Have you sent in feedback? I did regarding OS X — it sounds like you guys should do the same for your platforms.
The Windows version isn’t out yet… And I’m pretty sure @nox was referring to OSX too.
Also, I understand this forum as a place where to put feedback.
I sure hope @nox wasn’t talking about OS X — XDG is a Linux standard, and apps on OS X should be following Apple’s guidelines for storage of preferences and other application-specific data.
“like any sane person would do”
I’m fine with a
~/.config idea, but please don’t push stuff into
~/Library on OS X. I’d prefer to follow most other editors and keep my configs in a normal dotfiles location, especially one that works in OS X and Linux. Personally, I prefer to even have my Windows configs in
Same as @jredville. I’d much prefer being able to keep my editor config in my dotfiles repo.
.atom should definitely be moved to ~/Library/Application Support/Atom since that is the system standard.
The files should be put in
~/Library on OS X, in
%APPDATA% on Windows and in
~/.config on Linux. Furthermore, it should be possible to change the settings to tell Atom to go look for its files in some arbitrary location, and it would be interesting to have an option in the settings panel to have it be put in
~/.config on Mac OS X or
%HOME%/.config on Windows. I think this satisfies everyone.
Either way, the standard locations for the different operating systems should be followed and there should be a setting to give an arbitrary location.
As much as I love system standards when it comes to the Mac, I think this is one area where we should make an exception. The Text Editor is unlike other GUI apps such as Keynote or Pixelmator. These are configs that we need to keep within easy reach in the event that we need to
- Share them with another a machine
- Look up a setting to share with a mate
- Keep them backed up with the rest of our configuration
Or anything else we might want to do with them. At the end of the day we’re talking about a text editor for developers here. And for developers, the “system standard” is be dotfiles. Regardless of Unix-flavor.
There’s no reason that they can’t follow Apple standards, like putting config in ~/Library/Application Support/ and still let you symlink things into your dot files. I have often used symlinks in this way without issues. The kinds of people worried about ~/.atom vs ~/Library and dotfiles, are the same kinds of people that can probably easily symlink things from the Apple standard to their own standard layouts
In my ~ I have .npm, .dropbox, .xmbc, and .android. It seems that it’s at least a standard to some degree.
I think a reasonable approach to this on OS X would be to allow both the
~/Library/... approach but also check for a
~/.config/atom path. This would be similar to TextMate’s approach of having preference files and also checking for
I think that on OS X, it should be kept in the system standard location (~/Library/Application Support/Atom). I do not think there should be an option to move it to ~/.atom.
If a user really wants to have it located in ~/.atom (say for syncing purposes), they can move it / have it sync to that location and then symlink the config folder to ~/Library/Application Support/Atom.
~/Library is “super” hidden by default, I think you would be asking for more support requests putting it there. Even though users of Atom are probably going to be power users, I’m certain you’ll have power users who don’t usually play with
~/Library. The fact that ST puts the config in
~/Library is actually one of the things I don’t like about it.
~/.atom matches a much older convention, and is much more portable than OS X standards. It’s also intuitive to dev’s who are used to using the shell, and it’s already where many libraries put their config as well (Node, various Ruby libs, Scala, Haskell, Dropbox, Postgres, etc).
~/Library is no more hidden than
%AppData% on Windows – in fact, far less so.
I would push for
%HOME%/.atom on Windows as well, that’s where I keep my Vim config.
~/Library is also more hidden than
%APPDATA% is just a normal hidden directory on Windows,
~/Library is a special attribute that tends to come back after upgrades.
As far as I’m aware,
~/Library is just a hidden directory on OS X as well. But it’s not split into
LocalLow/ which is completely dependent on the devs of the specific app to decide where it goes. Instead, it follows a set structure, that you can easily get to (⌘⌃G “~/Library”).
I don’t understand why it’s so difficult to simply follow the correct operating system’s structure and then allow users to symlink to their
%HOME% folder if that’s what they want. It keeps the system clean for the rest of us, the way it was meant to be, and allows those who want that option to have it.
Again, it’s something that could be added as a setting somewhere, but then you’re bloating the settings with superfluous options (see phpStorm.)
I think it would be both more “polite” and more conventional for Atom to read settings through a chain of locations. Here’s my suggestion:
- First read the global settings from the platform standard location:
/Library/Application Support/Atomon Mac
/etc/atomon XDG systems
- Maybe from
- Then read the user settings from a configurable location that defaults to the platform standard:
~/Library/Application Support/Atomon Mac
~/.config/atomon XDG systems
Thus with this system you can use the global settings or symlinks to have your user settings in the same place on different machines. This system also has the benefit of being well-behaved in accordance with the standards for each platform and avoids unnecessary pollution of the home directory.
(Also, I think this debate over the hiddenness of
%APPDATA% is a little pointless: we’re all developers, and we all know how to get there.)