I've evangelised this tool on every team I've worked with for years. It eliminates _so_ many forms of conflict and bikeshedding. (Plus I have contributed in a trivial way to the Emacs plugin; they very happily accept PRs).
EditorConfig – file format for defining coding styles and text editor plugins
11–20 of 32 posts
Re: EditorConfig – file format for defining coding styles and text editor plugins
#12Before clicking on the link, I thought "Oh, just another attempt at standardizing editor preferences from a file in a repo." But looking at their list of editors which natively support EditorConfig and the list of plugins for editors which don't, this is far better support than I imagined. This is it! Problem solved.
Honestly I don't think much is solved by EditorConfig. I mean, the idea is great, but the small amount of parameters supported makes it pretty much useless. Indentation character and size, line termination, ... and that's all. I would need a hundred of these (like clang-format, yapf, etc have) to switch to EditorConfig. Unfortunately, looking at the commit log frequency, I doubt EditorConfig will ever have more than…
but what more could it have? Editor config is not a "should there be a space between function name and parens" kind of tool.
It's only meant to automatically configure your editor to use the defined tab/space newline preferences per file type.
that's it.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#13People comparing EditorConfig to eslint or prettier does not really understand it's purpose.
yes they have intersecting features, but EditorConfig's main feature is that it lets you set file type specific whitespace rules automatically, across almost all editors.
- Most editors will have a global whitespace rule and you have to use that same rule for every file.
- Some editors can be configured to have different rules per file type but then it can't be done per project. So every project has to use the same rules.
- Some editors will let you configure all of these per project, but you have to save this project-settings file somewhere. Editor specific code is no good in the repo, so you need to maintain/backup it yourself.
EditorConfig solves all of these issues for me.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#14Before clicking on the link, I thought "Oh, just another attempt at standardizing editor preferences from a file in a repo." But looking at their list of editors which natively support EditorConfig and the list of plugins for editors which don't, this is far better support than I imagined. This is it! Problem solved.
Honestly I don't think much is solved by EditorConfig. I mean, the idea is great, but the small amount of parameters supported makes it pretty much useless. Indentation character and size, line termination, ... and that's all. I would need a hundred of these (like clang-format, yapf, etc have) to switch to EditorConfig. Unfortunately, looking at the commit log frequency, I doubt EditorConfig will ever have more than…
Yes, it doesn't have many features, but most everything I might want should be defined elsewhere. Astyle configs should go in its own `.astylerc` file, Python style in `.style.yapf`, clang-format in `.clang-format`, build system in `Makefile` or `Gruntfile` or whatever is most common in your language, `.gitignore` for useless files, etc. But just for displaying a file perfectly, all that's needed is file encoding and indent width, and a couple other things EditorConfig defines. It's not supposed to be an "IDEConfig".
Re: EditorConfig – file format for defining coding styles and text editor plugins
#15Before clicking on the link, I thought "Oh, just another attempt at standardizing editor preferences from a file in a repo." But looking at their list of editors which natively support EditorConfig and the list of plugins for editors which don't, this is far better support than I imagined. This is it! Problem solved.
Honestly I don't think much is solved by EditorConfig. I mean, the idea is great, but the small amount of parameters supported makes it pretty much useless. Indentation character and size, line termination, ... and that's all. I would need a hundred of these (like clang-format, yapf, etc have) to switch to EditorConfig. Unfortunately, looking at the commit log frequency, I doubt EditorConfig will ever have more than…
> Honestly I don't think much is solved by EditorConfig.
No, it doesn't solve all the things. My experience is that it addresses one specific annoyance - team members checking in changes with varying line endings and spaces/tabs settings - and makes it a thing of the past.
For solving that one thing, I like it a lot.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#16At least in the JavaScript world, this was a lovely thing to have. Now we have linters which are even better! Still nice to include this so that all collaborators don't need to modify their editors to jump in!
Do not compare it to linters they serve a different purpose. Editorconfig is for using the right editor settings, linters are for programmatically checking and formatting code. So Editorconfig and a linter should be used together.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#17Looks like 99% of this is covered by my editor being configured to autodetect existing indentation, and adjust itself accordingly: https://github.com/ciaranm/detectindent
Re: EditorConfig – file format for defining coding styles and text editor plugins
#18Earlier quoted context omitted.
Honestly I don't think much is solved by EditorConfig. I mean, the idea is great, but the small amount of parameters supported makes it pretty much useless. Indentation character and size, line termination, ... and that's all. I would need a hundred of these (like clang-format, yapf, etc have) to switch to EditorConfig. Unfortunately, looking at the commit log frequency, I doubt EditorConfig will ever have more than…
> Honestly I don't think much is solved by EditorConfig. No, it doesn't solve all the things. My experience is that it addresses one specific annoyance - team members checking in changes with varying line endings and spaces/tabs settings - and makes it a thing of the past. For solving that one thing, I like it a lot.
Well, it moves the problem to making sure that all team members have the right plugins installed and bother to use them. Depending on the make up of your team, that could be a hard problem.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#19Earlier quoted context omitted.
> Honestly I don't think much is solved by EditorConfig. No, it doesn't solve all the things. My experience is that it addresses one specific annoyance - team members checking in changes with varying line endings and spaces/tabs settings - and makes it a thing of the past. For solving that one thing, I like it a lot.
Well, it moves the problem to making sure that all team members have the right plugins installed and bother to use them. Depending on the make up of your team, that could be a hard problem.
It moves the problem from "could you submit your PR with spaces not tabs, the spurious diff is not good" and "but it doesn't matter, I don't care" on a regular basis; to "let's install this plugin to your IDE and neither of us has to worry about it again - you get ease and I get consistency".
If this is really a hard problem for a team then it's down to the people not the tools.
There is in my experience no "bother to use them" part, it happens automatically when a file is saved.
Even better, "the right plugins" might be none at all. Some IDEs come with editorconfig support out of the box: https://sorokoletov.com/2016/11/28/editorconfig-in-visualstu...
In short, if you have these specific problems, life really is easier with editorconfig.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#20"LSP for indentation" :)