For example the team I work in, PHP needs to have 4 space indent, instead of my general setting of 2.
Currently I update all of these instances using the init.coffee, but that’s less than ideal.
For example the team I work in, PHP needs to have 4 space indent, instead of my general setting of 2.
Currently I update all of these instances using the init.coffee, but that’s less than ideal.
We’ve discussed this internally but haven’t thought of a solution we love yet. We’d love to here how people would like this to work.
This could be a part of the Language settings in the plugin panel
I was thinking about this the other day … I think Git has a really good model for this kind of thing. But first …
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:
~/.atom/config.cson
{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.
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:
editor = atom.workspace.getActiveEditor()
syntaxSpecificLength = editor.config.get('editor.preferredLineLength')
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:
~/.atom/config-foo.cson
{project root}/.atomconfig-foo
The grammar-specific settings could instead just be stored inside the already existing config files like so:
'editor':
'tabLength': 2
'grammar': # Maybe this should be 'language' instead?
'python':
'editor':
'tabLength': 4
Anyway … just some thoughts. Let me know what you think!
Hey,
I wanted to try what’s possible, and I ended up publishing https://atom.io/packages/language-syntax-settings. Please tell me if it works as you’d expect and inform me of any issues.
.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:
'editor':
'showInvisibles': true
'invisibles':
'cr': '↩'
'eol': ''
'space': '·'
'tab': '⇥'
It also appears that .editorconfig only accepts atomic values for keys, whereas CSON accepts arrays:
'core':
'themes': [
'atom-dark-ui'
'railscasts-syntax'
]
'disabledPackages': []
'ignoredNames': [
'.git'
'.svn'
'.DS_Store'
]
I really like the fact that Atom uses CSON for configuration, like Sublime Text uses JSON. It is just much more flexible than the standard INI file format.
I have just created a package that does this, and the settings 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.