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?
+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:
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.
+1, I also couldn't find this in the documentation, but glad it works.
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.
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.
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.
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.
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:
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?
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
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!
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.
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.
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?
@florianb You can file an application if you still want to...
@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.
@florianb I agree with everything you just said.
What do you think about unset as the reserved value?
+1 for unset WFM.
I noticed max_line_length is documented to use off.
Interesting! Looks like we should stick with off for consistency then.