Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add default rules for YAML files #329

Open
sindresorhus opened this issue Nov 9, 2017 · 15 comments
Open

Add default rules for YAML files #329

sindresorhus opened this issue Nov 9, 2017 · 15 comments

Comments

@sindresorhus
Copy link
Member

YAML files can only be indented by 2 spaces. Tab-indentation is invalid. It would be nice if EditorConfig just defaulted to this for YAML files as it's the only way to do it. It should not be overridable.

Currently, I have to have a YAML specific override in every single .editorconfig file, which is annoying and feels moot: https://github.com/sindresorhus/xo/blob/8ac0f3e25426937ef96288dfbe7d4dfda857c9bf/.editorconfig#L10-L12

@ffes
Copy link
Member

ffes commented Nov 9, 2017

Just to be sure. You mean that when a .yml file is opened it should automatically set the tabs right, regardless of the content of .editorconfig?

@SamVerschueren
Copy link

Not sure if this is what you mean but what I believe @sindresorhus means is that .editorconfig should always default to 2 spaces for .yml files and omit the settings of the user .editorconfig. This way, the plugins of the individual IDE's don't have to take care off it because the editorconfig module always returns 2 spaces for .yml files.

Totally agree on this, would be easier and cleaner to configure.

@sindresorhus
Copy link
Member Author

What Sam said.

@florianb
Copy link
Member

florianb commented Nov 9, 2017

As far as i understand the YAML-spec, the number of spaces for intendation is not defined in general.

However - i'd prefer considering a general default-mechanism (applicable for other file types, too). But i also see the danger of people relying on defaults not knowing where they're coming from, since the EditorConfig-standard is yet not specifying/suggesting if/how applied settings should be displayed to the user.

@ffes
Copy link
Member

ffes commented Nov 9, 2017

Is it something the core libraries of EditorConfig CAN take care? Probably.

I is also a matter of: is this something EditorConfig SHOULD take care of?

All the core libraries need to support this, all the plugins and the editors that support EditorConfig out of the box have to get updated. Not an easy task.

And where do you end? I know that Make and Go use tabs for indention. There probably will be other languages out there that have similar requirements as well. Every time somebody wants add a new language, all the steps above need to be taken.

I like the idea, but I'm not sure about how achievable it is.

I think this is related to #298 as well.

@sindresorhus
Copy link
Member Author

@ffes The difference is that YAML enforce space indentation. That's not the same as a convention.

@ffes
Copy link
Member

ffes commented Nov 9, 2017

@sindresorhus The same goes for Make. A makefile file with space indentation won't work.

@binki
Copy link

binki commented May 29, 2018

Maybe YAML requires spaces, but does it actually require 2 spaces? #298 (comment) seems to state otherwise.

@AlexWayfer
Copy link

Maybe YAML requires spaces, but does it actually require 2 spaces? #298 (comment) seems to state otherwise.

Yes, looks correct.

@jnns
Copy link

jnns commented Nov 23, 2018

What about another file type spec that uses the YAML extension(s)? In that case I'd like the defaults to be overridable and not be forced upon me.

EDIT (added quote I was referring to):

It would be nice if EditorConfig just defaulted to this for YAML files as it's the only way to do it. It should not be overridable.

@AlexWayfer
Copy link

What about another file type spec that uses the YAML extension(s)? In that case I'd like the defaults to be overridable and not be forced upon me.

What? You can override anything, of course. It's just default content of generated config files, as I understood.

@AlexWayfer
Copy link

Oh, we already have default YAML and other configs…

https://github.com/editorconfig/editorconfig-defaults

I guess, we should ask plugins maintainers to support these defaults.

@ffes
Copy link
Member

ffes commented Nov 27, 2018

I guess, we should ask plugins maintainers to support these defaults

You are absolutely right.

Small problem is that the file format is not final yet. There is an open PR that finally needs to be finished. (Note to self)

@craigbarnes
Copy link

craigbarnes commented Jun 16, 2019

The same goes for Make. A makefile file with space indentation won't work.

It isn't like YAML where any form of tab indent is invalid though. It only applies to "recipe" indents in makefiles and GNU Make even let's you change the character (by setting .RECIPEPREFIX).

@septatrix
Copy link

As some others already said the same can be said about Makefile (where tabs must be used), *.md (where trailing whitespace is important), many files which require utf-8 and the list goes on. As @ffes already said there becomes a point where editorconfig maintainer have to make a decision where to stop and at that point editorconfig becomes very subjective.

I like editorconfig because it does the exact minimum required to do a lot of things right for a plethora of IDEs. Implementing such defaults would be against its spirit apart from the many integrations which have to be updated (or not, in which case different IDEs may behave differently). It is not like one has to write an .editorconfig every day and this would save hundreds of keystrokes. And if you do then I hope that there is simply a template which you copy and paste.

Apart from that there are many other differences between how IDEs format yaml files such that one most certainly would need to put a config file for some of these formatters in a repo anyhow if it contains many yaml files which are updated often.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants