Hacker News Reader

Comment by vortico | Hacker News Reader

Before 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.

View on HN

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 the 10 or so parameters that it already have.

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.

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".

> 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.

I hope it does. It's to add them slowly though. Especially since most editors have built in settings for spacing but not for linting. I wish for stuff like allowed_var_name_regex that would mean nothing to most editors unless you install a plugin.

Reply on news.ycombinator.com