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.
Per Language/Syntax Settings
5 Likes
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 …
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:
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:
- 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:
'editor':
'tabLength': 2
'grammar': # Maybe this should be 'language' instead?
'python':
'editor':
'tabLength': 4
Anyway … just some thoughts. Let me know what you think!
4 Likes
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.
3 Likes
.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 agree, that is quite more powerful!
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.
4 Likes