Document ability to disable rules #282

Open
glennpratt opened this Issue Nov 30, 2016 · 19 comments

Projects

None yet

5 participants

@glennpratt

insert_final_newline has behavior in both documented cases.

insert_final_newline: set to true to ensure file ends with a newline when saving and false to ensure it doesn't.

I'm sure other properties are in the same boat.

Setting that value to something invalid works, at least with the plugins I use, but why not reserve a null value and document it?

@sterpe
sterpe commented Dec 1, 2016 edited

+1. The best example is *.md files which use both tabs and spaces as part of markdown syntax purposes. Because of the cascading way .editorconfig settings work, it's much easier to turn a rule such as indent_style 'off' for [*.md] than it is to enable the correct indent_style for every file type specifically. I want this:

[*]
indent_style=space
indent_size=2

[*.md]
indent_style={null,none,ignore,off,,}
@jedmao
Member
jedmao commented Dec 2, 2016

This feature is already supported and has been for a very long time. You can use null, none, ignore, off or even foo if you want. Anything that's not supported will remove the setting for you.

@jedmao jedmao closed this Dec 2, 2016
@glennpratt
@sterpe
sterpe commented Dec 2, 2016

+1, I also couldn't find this in the documentation, but glad it works.

@jedmao
Member
jedmao commented Dec 3, 2016

I don't think we want to define a specific value, as there are so many current implementations with all sorts of variations, but I support the idea of documenting the feature. I know it's been brought up in the past and it's definitely a source of confusion, so there's definitely some value there. Reopening this ticket.

@jedmao jedmao reopened this Dec 3, 2016
@jedmao jedmao changed the title from Define a null or none property to disable property. to Document ability to disable rules Dec 3, 2016
@florianb
florianb commented Dec 9, 2016

In order to let this standard finally become explicit i would really suggest defining a single specific value since this would avoid a lot of confusion in the future.

@jedmao
Member
jedmao commented Dec 9, 2016

I still don't think it's worth introducing a breaking change, so unless another EditorConfig member agrees, I think we'll have to preserve existing functionality and just document it.

@florianb
florianb commented Dec 9, 2016

I guess i don't get it. Is there any property that allows a value being f.e. auto? If not this doesn't break anything but instead makes a common practice (whose behaviour isn't defined, too) explicit.

But i guess I don't have a complete overview.

@jedmao
Member
jedmao commented Dec 9, 2016

I really don't see the point in saying/defining a single "supported" value, when in all actuality, we don't support the value at all! In fact, the fact that it's an unsupported value is what allows it to work by overriding supported values. Calling out some fake-supported value would be more confusing, because people would wonder why a particular setting that's not supported is removing a setting, when there is no documented "supported" value suggesting it should do anything at all!

Consider the following statements:

A Ford Focus can take you from point A to point B.

  1. Are you implying that my Mazda CX-9 can not also take me from point A to point B?
  2. Is there something special about the Ford Focus? You didn't clarify.
  3. Is there something special about Ford? You didn't clarify.

A Ford Focus can take you from point A to B. Any other make/model can also take you from point A to point B, so long as it's not on the list of reserved cars.

Thanks for clarifying that any make/model can also take me from point A to point B, but isn't that a bit redundant to say? I mean, why even bring it up? Why don't you just tell me that all makes and models of cars that are not on the reserved list can take me from point A to point B in the first place and call it a day?

All makes and models of cars can take you from point A to point B, so long as it's not on the list of reserved cars.

OK. This makes sense. No additional (useless) details have been added to create confusion.

Also, remember that you can have some fun with this particular feature. For example:

[*]
charset = utf-8
indent_style = space
indent_size = 4
end_of_line = lf
insert_final_newline = true

[*.json]
charset = rambo
indent_style = undo
indent_size = whatever
end_of_line = null
insert_final_newline = nah

This would totally work! Make spam your organization's official value to remove an EditorConfig setting if you want. That might make sense if you were working on a Python project, right? Oh, but you don't like spam? How about spam, eggs, sausage and spam? That ain't got much spam in it!

I don't like spam!

Point is, you can use whatever you want, so go ahead and do that and have fun with it. If you say "too much" you will confuse people.

@glennpratt
@jedmao
Member
jedmao commented Dec 10, 2016

Documenting how to disable rules is not the issue. I've agreed with that part of the request. The issue is taking it a step further and recommending a single "unsupported" value. If we want to provide examples, that's fine too. I'm just not feeling this single unsupported value, as if there's something special about it.

@xuhdev
Member
xuhdev commented Dec 12, 2016 edited

Since we now have a formal procedure to accept format changes now, do you guys want me to put this on the agenda, i.e., formalization of disabling values?

@xuhdev
Member
xuhdev commented Dec 12, 2016

@florianb You can file an application if you still want to...

@florianb

@jedmao i gave your answer some days to settle.

At first i must beg for pardon because it seems i wasn't able to express my intention in the right way.

I still disagree even though i guess i understand your point of view now. As far as i understand you want to avoid any more bloating by adding "unnecessary" content.

I would agree with that if we wouldn't reoccurring face users which are unsure how to explicitly express that a value should be explicitly not touched by editorconfig. This adds efforts for the users and for the maintainers since the users must guess and/or research how to achieve this functionality. A part of these users will try to get answers of their maintainers (search for disable/none/undefine in the issues).

I would define a single reserved value which explicitly disables its property.

This makes us no effort (than writing this single line) but will stop people asking how to disable a property. This wouldn't even break anything, since all these fantastic values like "rambo" would still be treated as invalid.

@jedmao
Member
jedmao commented Dec 13, 2016

@florianb I agree with everything you just said.

@jedmao
Member
jedmao commented Dec 13, 2016

What do you think about unset as the reserved value?

@sterpe
sterpe commented Dec 14, 2016

+1 for unset WFM.

@glennpratt

I noticed max_line_length is documented to use off.

@jedmao
Member
jedmao commented Dec 14, 2016

Interesting! Looks like we should stick with off for consistency then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment