I was thinking about this the other day … I think Git has a really good model for this kind of thing. But first …

Requirements

Allow nested configuration options — already covered

Allow language-specific overrides

Allow project-specific overrides (some projects have a line length limit of 80, some 72, some 100)

Design

We currently have a nested object hierarchy of settings. These are described as dot-separated strings, much like DNS hostnames except with the most significant identifier first.

What Git does is loads the configuration files in a particular order, allowing later ones to override earlier ones. Atom could employ something similar. Let’s start with project-specific settings because they’re easier:

Project-Specific Settings

Load ~/.atom/config.cson

Load {project root}/.atomconfig

So, for example ~/.atom/config.cson:

'editor':
'preferredLineLength': 100

And then in ~/some-project/.atomconfig:

'editor':
'preferredLineLength': 80

All that’s necessary is the ability to merge two objects, letting settings in the successive locations override the settings in the preceding locations.

Language-Specific Settings

Now this is a little harder because, right now, settings are global to all Atom sessions. But, since Atom determines the appropriate Grammar from the file’s path and contents (at least, that’s what I presume from GrammarRegistry.selectGrammar()) … Atom could tie grammar-specific settings to the TextBuffer or Editor instance. So I could do this:

Or I could get the default setting by accessing it through the standard method:

defaultLength = atom.config.get('editor.preferredLineLength')

Observers could be set in similar ways.

Now, how would Atom store these grammar-specific settings? Well, we already have a convention for grammar packages to be named language-foo. So I would suggest having grammar-specific override files be stored next to their global and project-specific counterparts with the grammar name in them, perhaps like:

Global — ~/.atom/config-foo.cson

Project-Specific — {project root}/.atomconfig-foo

The grammar-specific settings could instead just be stored inside the already existing config files like so:

.editorconfig, as I understand it from skimming the file format portion of the site, only allows one level of nesting of configuration information. Some things I already have in my configuration that, as they are currently written, require more nesting:

I have just created a package that allows for per language/syntax settings which can be saved within the main config.cson. It works off the file extension at this point. An example can be found at the package page. ...