The idea seems very cool, but I wonder if there is anything like this that could have more language specific stuff like "in JS (or Ruby, or ...) format your hashes/object literals/arrays/constants/... like so."
I like this, but the list of supported properties seems pretty short. I can see there might be some difficulties making it language-aware since the file formats are simple globs, but maybe you could say something like:
[*.js]
language_style = javascript
and somewhere describe that language_style in more detail.
The nice thing about EditorConfig is that it fixes some problems before they occur instead of requiring you to manually fix things after running a linter (e.g. spaces vs tabs)
EditorConfig is excellent. Straightforward to write a configuration file and pretty great editor support. I've only ever used the Vim plugin, but it works seamlessly such that I don't even notice.
Might it make more sense to rather compile the editorconfig file into the respective editor's config file? That way you need not depend on a plugin being written for the editor. This would mean that you could support more editors and enhance editor configurations without having to wait for the plugin to update to support your own new features. This would be at the cost of the ease of simply editing a single file, though it could be set up that, when compiled, the system will back the old config file up and insert the new one in its place.
EditorConfig support built-in to your text editor is the pipe dream. JetBrains 9 will have EditorConfig support, but no other editors yet support it natively so all of the plugins are necessary currently.
Unfortunately many editors do not support project-level configuration files by default. A conversion tool could be a good way to make global configurations even more accessible for editors that do support project configuration files and don't have native EditorConfig support yet.
Until native support becomes more common, EditorConfig acts as an unopinionated universal editor-level linter of sorts.
Then this would mean that you would have to compile this for every editor anyone editing the code base chose to use. It also means someone editing the code would have to manually copy the config file into the correct location. This kills the fact that EditorConfig plugins can automatically change settings per project, which is where a lot of the usefulness comes from IMO.
I've been using this for at least a couple of years and was expecting it to develop further (offer more common settings for editors) and to gain native support as, for example, the Sublime Text plugin loads the file using default tab size, then EditorConfig plugin kicks in and changes tab size to 4, let's say, which causes a full redraw and that always annoys me.
Great! Let's keep spreading awareness so that this becomes a high-demand item for each editors! I personally commit to make a PR to each major project I use as I found out about EditorConfig just by being curious about the config file in a project, so, this will definitely boost adoption.
Combine with something like https://github.com/schorfES/grunt-lintspaces to check that all code complies + some tests before or after you push your code upstream to eg. Git and you'll get a much more consistent code base when it comes to whitespaces.
I'd love to see an editor that let me see the code in the way I preferred (perhaps even as far as rendering Java as Lisp), but wrote the code to disk according to the EditorConfig.
From what I've seen, people sometimes accomplish this with git hooks. Well, not exactly what you want, but the basic: you see something different as is eventually saved to repository (and vice versa).
I like this, but the list of supported properties seems pretty short. I can see there might be some difficulties making it language-aware since the file formats are simple globs, but maybe you could say something like:
and somewhere describe that language_style in more detail.