AutoCrlf support (end_of_line = native)

[otac0n]

Git supports checking files out with native line endings.

You can specify this per file type, as well, using a .gitattributes file:

* text=auto

I would like to be able to support this similarly in my .editorconfig files.

I recommend adding an option native to end_of_line, indicating that the file should be forced to use native line endings:

[*]
end_of_line = native

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ffes]

I am really not sure on this one. As a (mainly) Windows developer who is using Cygwin and WSL to do all the git interaction I create (!) my own multi-platform issues. And for personal project I also put Linux in the mix for some of my development. So I am going through the pain of line endings a lot. I also (try to) force all the line endings within a project.

Having said that I don't see the big difference between unset and native. It is not clear (at lease to me) what the exact (aka practical) difference between native and unset option will be. unset stop EditorConfig to handle the line ending, which result in falling back to the default of the editor, which is native. So unset == native as far as I can see.

So I will vote against at this proposal as it stands at this moment. But with better documentation I could be convinced easily ;-)

[xuhdev]

@ffes unset does not necessarily lead to native -- on my Windows box I have every code editor default to LF line ending :)

[jednano]

@xuhdev exactly!

1. unset says, essentially, "Don't let EditorConfig enforce anything here. Just default to whatever user settings they might have."
2. native says, "Despite what user settings might exist, go ahead and force the native line endings on this particular file."

[treyhunner]

I feel like I'm in a similar camp to @ffes. I fear that native might end up being a bad idea in practice. I'm not sure whether it actually will because I really don't know whether I understand the usage well enough.

What would/should we recommend for those who want to use the native option? Should we recommend that everyone using end_of_line = native also put a .gitattributes file next to the .editorconfig file with a particular setting?

[jednano]

@treyhunner, I think that would be a good and useful example scenario, but we can't exactly make the assumption that they are using Git. There could be other useful ways of pairing version control settings with end_of_line = native that are equally useful, but we shouldn't need to know all of those scenarios. If it's useful in one scenario, it's potentially useful in others.

Also, to be clear, the .gitattributes file doesn't need to be "next" to the .editorconfig file; though, that would be the most common and likely scenario.

@ffes I totally understand your confusion and lack of clarity. Let me attempt to document the feature better:

end_of_line

value	description
lf	Enforces \n line endings (Mac/Linux). A popular setting among cross-platform projects.
crlf	Enforces \r\n line endings (Windows). A popular setting among Windows-only projects.
unset	Turns off plugin enforcement for line endings, falling back to user/workspace settings. Warning: mixed line endings can easily be introduced with this setting.
native	Enforces native line endings. *Warning: This is an uncommon setting; however, it remains useful for scenarios in which, for example, [Git is configured to normalize line endings on check-in via .gitattributes ` text=auto`](https://git-scm.com/docs/gitattributes#_end_of_line_conversion). If this is not you, you probably don't need it, so don't use it unless you are confident that it fits your particular scenario.**

See also: Plugin Guidelines#end_of_line.

I really think any more description than the above would be too confusing to the user. Most people will steer away from the native setting unless they truly know what they are doing. This is because the settings at the top are encouraged with language like "popular among such-and-such projects."

Disclaimer: As with any EditorConfig setting, any misuse comes at your own risk. Introduce new configuration settings with caution and care. Also, please feel free to reach out with any questions about a particular setting.

[florianb]

I am just curious - why is it not possible to leave the editor to it's default and define an end_of_line via Editorconfig where necessary? I guess you achieve the same if you're going to save your project in a subfolder containing a Editorconfig enforcing lf (or whatever).

[jednano]

@florianb I think @xuhdev explained it best, "on my Windows box I have every code editor default to LF line ending." In his case, we would need to override his user/workspace settings with end_of_line = native to ensure LF line endings are not introduced on particular files (on Windows).

[florianb]

Thanks @jedmao, I guess I got that but why setting all editors to lf on windows instead of keep them on default and use EditorConfig to specify the EOL explicitly where necessary?

[jednano]

@florianb, I can think of a number of reasons:

1. Not all projects have an .editorconfig file and some teams are a bit resistant to the inclusion of it. We can't assume perfect-world conditions for everyone.
2. The .editorconfig file at the project root might not have root = true.
3. The project might already have a .gitattributes file with * text=auto, in which case, a setting of end_of_line = lf could be fighting against it (on Windows).

Perhaps there are more, but those came easily.

[xuhdev]

@florianb The majority of the code I dealt with is cross platform, and most of them uses LF only strategy. That's why I have LF settings on Windows.

[kfsone]

If the goal is to fix the toolchain then "editorconfig" seems like the wrong name. Rather than a tool that attempts to let a heterogeneous assortment of editing tools work consistently and across platforms, it tries to participate in the eol catastrophe by allowing a file to define eol in a file.

Unset means that editorconfig does not contribute to configuration of eol.

Native says: yes you do, but what you set it to depends on the native default for the platform.

If a user has LF set in their use, I do not want them putting LFs in a file that will expect CRLF.

That's what native does. There are scripting languages that use native self, and if I specify "CRLF" then the resulting scripts work on Windows but break on Linux.

There are cases of generated files with native eols that may be /viewed/ in an editor but need to not tamper with eol style, as they would with @xuhdev's editor setting.

[kfsone]

'native' is the option if need if @xuhdev was on our team for SOME files that absolutely have to use the native eol.

"you should fix the tool chain" MERP wrong answer, Microsoft/Apple circa 1980.

Maybe I should fix my tool chain, or maybe I should spend less time on the problem and add two lines of commit hook that rejects the wrong eols and reduces the author's annual bonus %age.

:)

[ffes]

@jedmao The documentation you wrote is very clear to me. When this will become the official docs for this feature, my main objection against this proposal is gone and I will change my vote to 👍

[jednano]

The voting has concluded and 👎 was the outcome, so no feature will be implemented. Thanks everyone for your contributions to this issue, but I'll be closing/locking it now, as it has been exhausted enough.